Mbed TLS is now part of TrustedFirmware.org.

Handshake Messages are not fragmented


Apr 18, 2018 15:09
Bill Carter

I'm running a client that is attempting a handshake with a webserver.

The code that is invoking the handshake looks like this (returns an error code of -7200); ret = mbedtls_ssl_handshake(&o->ssl)

The server that is showing the failure (my server) is at the following URL; https://canulus.com

The webserver is running Nginx and the certificate shows as good when I run the usual 3rd party checks against it. Can you shed any light on what might be the problem?

 
Apr 18, 2018 15:37
Bill Carter

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_cli.c:1641: dumping 'server hello, session id' (0 bytes)

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_cli.c:1679: no session has been resumed

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_cli.c:1681: server hello, chosen ciphersuite: c030

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_cli.c:1682: server hello, compress alg.: 0

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_cli.c:1698: server hello, chosen ciphersuite: TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_cli.c:1733: server hello, total extension length: 17

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_cli.c:1753: found renegotiation extension

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_cli.c:1832: found supported_point_formats extension

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_cli.c:1237: point format selected: 0

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_cli.c:1818: found session_ticket extension

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_cli.c:1922: <= parse server hello

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_cli.c:3363: client state: 3

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_tls.c:2416: => flush output

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_tls.c:2428: <= flush output

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_tls.c:4320: => parse certificate

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_tls.c:3721: => read record

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_tls.c:2208: => fetch input

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_tls.c:2366: in_left: 0, nb_want: 5

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_tls.c:2390: in_left: 0, nb_want: 5

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_tls.c:2391: ssl->f_recv(_timeout)() returned 5 (-0xfffffffb)

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_tls.c:2403: <= fetch input

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_tls.c:3478: dumping 'input record header' (5 bytes)

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_tls.c:3478: 0000: 16 03 03 11 ea .....

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_tls.c:3487: input record: msgtype = 22, version = [3:3], msglen = 4586

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_tls.c:3518: bad message length

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_tls.c:3729: mbedtls_ssl_read_record_layer() returned -29184 (-0x7200)

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_tls.c:4360: mbedtls_ssl_read_record() returned -29184 (-0x7200)

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_tls.c:6567: <= handshake

read/write mbedtls_ssl_handshake error: -7200 cleanup DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_tls.c:7344: => free

DBG:/home/bill/esp32/LoBo3/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/mbedtls/library/ssl_tls.c:7409: <= free

 
Apr 19, 2018 15:54
Hanno Becker

Hi Bill,

the debugging output indicates that the Mbed TLS library running on the client is configured to have a too small value of MBEDTLS_SSL_MAX_CONTENT_LEN. Could you confirm?

If that is the case, note that the server must be informed about the limitations of the client through the use of the MaximumFragmentLength extension.

Note, though, that if the server henceforth fragments the problematic Certificate, this will, with the current version of Mbed TLS, not lead to a fix of the problem, because the client is unable to reassemble the incoming fragments.

But before we talk about this and potential remedies, could you check your client configuration, specifically the configured value of MBEDTLS_SSL_MAX_CONTENT_LEN, please?

Kind regards,

Hanno, Mbed TLS team member

 
Apr 19, 2018 21:10
Bill Carter

MBEDTLS_SSL_MAX_CONTENT_LEN is set to 16384, but it may be that the client can't allocate enough memory. The certificate I have been using is multiple-site, perhaps that makes it larger? It was almost expired, I replaced it with a single-site certificate and that is now working.

 
Apr 20, 2018 08:23
Hanno Becker

Hi Bill,

this is very puzzling. The debugging output clearly traces the failure back to this code path, which, together with the debugging information that the handshake message size is around 4k, implies that MBEDTLS_SSL_BUFFER_LEN is too small. An this in turn is defined in terms of MBEDTLS_SSL_MAX_CONTENT_LEN.

Kind regards,

Hanno, Mbed TLS team member