Closed skrulj closed 2 months ago
I think I've seen this before. It seems to be the same bug as https://github.com/Mbed-TLS/mbedtls/issues/8669, which is fixed in Mbed TLS 3.6.0. Please try upgrading Mbed TLS. Let us know if that doesn't fix the problem and we can reopen this issue.
Thank you for your reply. Update has indeed fixed the issue.
Summary
We have noticed some connection issues with certain servers when using MbedTLS 1.3 client functionality. A wireshark analysis has shown that the problem at hand is a changing client random between the first and 2nd "Client Hello".
RFC8446 does not explicitly allow a change of this field, but states the message must not change, except for the "key_share", "early_data" and "cookie" extensions in defined circumstances. https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.2
Some strict server implementations (e.g. picotls) are known for rejecting connections if the "client random" changes in second flight.
System information
Bare Metal STM32F427VI with DP83848K PHY and LWIP for the IP layer
Mbed TLS version (number or commit id): 3.5.1
Operating system and version: Bare metal Configuration (if not default, please attach
mbedtls_config.h
):Compiler and options (if you used a pre-built binary, please indicate how you obtained it): gcc-arm-none-eabi-10.3-2021.10 With the following flags:
Additional environment information:
Expected behavior
The client random in the 2nd "Client Hello" should be the same as in the first "Client Hello" after a "Hello Retry Request"
Actual behavior
The client random differs
Steps to reproduce
mbedtls_ssl_conf_min_tls_version(&tls_io_instance->config, MBEDTLS_SSL_VERSION_TLS1_3)
and the server prefers a different ECC group (e.g. usingmbedtls_ssl_conf_groups
), this will trigger a "Hello Retry Request"Additional information
A wireshark capture: First Client Hello:
Hello Retry Request
2nd Client Hello