verify_result should default to failure

[bryghtlabs-richard]

Summary

ssl_handshake_init() or mbedtls_ssl_session_init() should initialize ssl->session_negotiate->verify_result to an invalid result, and later MbedTLS should only set it to a valid result once the certificate has been validated(client) or understood that a certificate is not needed(server that does not require client certificates).

System information

Mbed TLS version (number or commit id): 3.6.4 c765c83
Operating system and version: ESP-IDF 6 development FreeRTOS
Configuration (if not default, please attach mbedtls_config.h): attached
Compiler and options (if you used a pre-built binary, please indicate how you obtained it): I don't think this is a compiler-related problem, but ESP-IDF 4e036983a7
Additional environment information:

Expected behavior

mbedtls_ssl_get_verify_result() must not return ok verify result until the certificate has been validated.

Actual behavior

Before the handshake is started, mbedtls_ssl_get_verify_result() returns 0(success) because ssl->session_negotiate->verify_result is initialized to 0(success).

The documentation states it should return 0 if successful, -1 if result is not available (eg because the handshake was aborted too early), or a combination of BADCERT_xxx and BADCRL_xxx flags, see x509.h. Seems like it should return -1 if called before handshake begins?

Steps to reproduce

1. Create an mbedTLS client-context with a session, as-if you were going to connect
2. Before connecting, call mbedtls_ssl_get_verify_result()

Additional information

Relevant documentation snippet: With MBEDTLS_SSL_VERIFY_OPTIONAL, the user needs to call mbedtls_ssl_get_verify_result() at the right time(s), which may not be obvious

I believe the fact that I've noticed this is an indication that ESP-IDF was calling mbedtls_ssl_get_verify_result() at the wrong time, which is a client-side bug outside MbedTLS, but defaulting to a failure code would make identifying this type of bug more obvious(see espressif/esp-idf#16239)

[davidhorstmann-arm]

Hi, thanks for this report!

I'll look into it further and get back to you, as I'm not immediately familiar with this part of the code.

[davidhorstmann-arm]

@bryghtlabs-richard I have raised #10443. Would you be able to check if this fixes the problem?

[bryghtlabs-richard]

@davidhorstmann-arm , I'm working from home without my test router, last day before I'm out for 2+ weeks.

I can confirm the happy-path for https clients is unaffected.

Edit: I don't think I'll be able to verify mbedtls_ssl_get_verify_result() doesn't spuriously return success anymore in our actual configuration until I'm back at the office.

[davidhorstmann-arm]

I don't think I'll be able to verify mbedtls_ssl_get_verify_result() doesn't spuriously return success anymore in our actual configuration until I'm back at the office.

That's okay, no rush! This will need to find review bandwidth from the team anyway, and that can take a while. I can check back in a few weeks and see where we're at.