ARMmbed

Mbedtls_ssl_handshake bad message length

I am using 2.9.0 release, TCP stream and async read. The handshake fails at parse server hello client state 2 with error bad message length (-0x7200). Logs show fetching input record header with a message length 3373. A read of only 5 bytes was requested so the input buffer does not have 3373 bytes. Shouldn’t the function ask for more bytes if it knows it only requested 5? Log dump below:

ssl_tls.c|6718| => handshake
ssl_cli.c|3389| client state: 0
ssl_tls.c|2473| => flush output
ssl_tls.c|2485| <= flush output
ssl_cli.c|3389| client state: 1
ssl_tls.c|2473| => flush output
ssl_tls.c|2485| <= flush output
ssl_cli.c|773| => write client hello
ssl_cli.c|811| client hello, max version: [3:3]
ssl_cli.c|820| dumping ‘client hello, random bytes’ (32 bytes)
ssl_cli.c|820| 0000: 02 e2 eb 95 57 c6 16 b8 33 95 78 ee dd b3 3c 1b …W…3.x…<.
ssl_cli.c|820| 0010: ce 8f 5f 01 55 4b 37 01 7b 9d 30 92 2e b2 82 35 ….UK7.{.0…5
ssl_cli.c|873| client hello, session id len.: 0
ssl_cli.c|874| dumping ‘client hello, session id’ (0 bytes)
ssl_cli.c|921| client hello, add ciphersuite: 009d
ssl_cli.c|921| client hello, add ciphersuite: 009c
ssl_cli.c|928| client hello, got 2 ciphersuites (excluding SCSVs)
ssl_cli.c|937| adding EMPTY_RENEGOTIATION_INFO_SCSV
ssl_cli.c|986| client hello, compress len.: 1
ssl_cli.c|988| client hello, compress alg.: 0
ssl_cli.c|189| client hello, adding signature_algorithms extension
ssl_cli.c|274| client hello, adding supported_elliptic_curves extension
ssl_cli.c|339| client hello, adding supported_point_formats extension
ssl_cli.c|588| client hello, adding session ticket extension
ssl_cli.c|1062| client hello, total extension length: 42
ssl_tls.c|2766| => write record
ssl_tls.c|2912| output record: msgtype = 22, version = [3:3], msglen = 93
ssl_tls.c|2915| dumping ‘output record sent to network’ (98 bytes)
ssl_tls.c|2915| 0000: 16 03 03 00 5d 01 00 00 59 03 03 02 e2 eb 95 57 …]…Y…W
ssl_tls.c|2915| 0010: c6 16 b8 33 95 78 ee dd b3 3c 1b ce 8f 5f 01 55 …3.x…<…
.U
ssl_tls.c|2915| 0020: 4b 37 01 7b 9d 30 92 2e b2 82 35 00 00 06 00 9d K7.{.0…5…
ssl_tls.c|2915| 0030: 00 9c 00 ff 01 00 00 2a 00 0d 00 12 00 10 06 03 …*…
ssl_tls.c|2915| 0040: 06 01 05 03 05 01 04 03 04 01 03 03 03 01 00 0a …
ssl_tls.c|2915| 0050: 00 06 00 04 00 18 00 17 00 0b 00 02 01 00 00 23 …#
ssl_tls.c|2915| 0060: 00 00 …
ssl_tls.c|2473| => flush output
ssl_tls.c|2492| message length: 98, out_left: 98
ssl_tls.c|2498| ssl->f_send() returned 98 (-0xffffff9e)
ssl_tls.c|2525| <= flush output
ssl_tls.c|2924| <= write record
ssl_cli.c|1088| <= write client hello
ssl_cli.c|3389| client state: 2
ssl_tls.c|2473| => flush output
ssl_tls.c|2485| <= flush output
ssl_cli.c|1481| => parse server hello
ssl_tls.c|3811| => read record
ssl_tls.c|2254| => fetch input
ssl_tls.c|2415| in_left: 0, nb_want: 5
ssl_tls.c|2439| in_left: 0, nb_want: 5
ssl_tls.c|2440| ssl->f_recv(_timeout)() returned 1 (-0xffffffff)
ssl_tls.c|2439| in_left: 1, nb_want: 5
ssl_tls.c|2440| ssl->f_recv(_timeout)() returned 1 (-0xffffffff)
ssl_tls.c|2439| in_left: 2, nb_want: 5
ssl_tls.c|2440| ssl->f_recv(_timeout)() returned 1 (-0xffffffff)
ssl_tls.c|2439| in_left: 3, nb_want: 5
ssl_tls.c|2440| ssl->f_recv(_timeout)() returned 1 (-0xffffffff)
ssl_tls.c|2439| in_left: 4, nb_want: 5
ssl_tls.c|2440| ssl->f_recv(_timeout)() returned 1 (-0xffffffff)
ssl_tls.c|2460| <= fetch input
ssl_tls.c|3554| dumping ‘input record header’ (5 bytes)
ssl_tls.c|3554| 0000: 16 03 03 0d 2d …-
ssl_tls.c|3563| input record: msgtype = 22, version = [3:3], msglen = 3373
ssl_tls.c|3601| bad message length
ssl_tls.c|3822| mbedtls_ssl_read_record_layer() returned -29184 (-0x7200)
ssl_cli.c|1488| mbedtls_ssl_read_record() returned -29184 (-0x7200)
ssl_tls.c|6728| <= handshake
mbedtls-ssl-handshake failed -0x7200 SSL - An invalid SSL record was received
ssl_tls.c|7519| => free
ssl_tls.c|7584| <= free

Found the problem - the fragment length was too low for the server to handle.