Hi everyone,

The company I’m working for uses mbedtls to drive an embedded TLS server (for HTTPS): but now needs the same device to also act as a TLS client for logging in to remote servers (e.g. for LDAP etc).

My embedded test code tries (but fails) to connect to a remote HTTPS server on port 443: I can connect to the same server via openssl on a desktop command line, so it seems to be working.

Basically, the client hello message goes out fine (for brevity, I’ve skipped all the ciphersuites, but note that the list does contain the 0xC030 ciphersuite that desktop openssl is able to connect to OK):

.ssl_cli.c:934: client hello, got 25 ciphersuites (excluding SCSVs)

.ssl_cli.c:943: adding EMPTY_RENEGOTIATION_INFO_SCSV

.ssl_cli.c:992: client hello, compress len.: 1

.ssl_cli.c:994: client hello, compress alg.: 0

.ssl_cli.c:186: client hello, adding signature_algorithms extension

.ssl_cli.c:271: client hello, adding supported_elliptic_curves extension

.ssl_cli.c:336: client hello, adding supported_point_formats extension

.ssl_cli.c:518: client hello, adding encrypt_then_mac extension

.ssl_cli.c:552: client hello, adding extended_master_secret extension

.ssl_cli.c:585: client hello, adding session ticket extension

.ssl_cli.c:1071: client hello, total extension length: 52

0000: 16 03 01 00 95 01 00 00 91 03 03 16 e9 7a ea aa

0010: 31 81 60 b6 a8 d3 32 93 a4 50 ca f3 e0 66 f8 47

0020: 56 95 0c cd a0 db b6 0e ae a7 d4 00 00 34 c0 30

0030: 00 9f c0 ad c0 9f c0 24 c0 28 00 6b c0 0a c0 14

0040: 00 39 c0 af c0 a3 c0 2b c0 2f 00 9e c0 ac c0 9e

0050: c0 23 c0 27 00 67 c0 09 c0 13 00 33 c0 ae c0 a2

0060: 00 ff 01 00 00 34 00 0d 00 16 00 14 06 03 06 01

0070: 05 03 05 01 04 03 04 01 03 03 03 01 02 03 02 01

0080: 00 0a 00 04 00 02 00 17 00 0b 00 02 01 00 00 16

0090: 00 00 00 17 00 00 00 23 00 00

However, the server hello that comes back is both unhappy and unhelpful:

.ssl_tls.c:2721: in_left: 5, nb_want: 7

.ssl_tls.c:2722: ssl->f_recv(_timeout)() returned 2 (-0xfffffffe)

.ssl_tls.c:2742: <= fetch input

.ssl_tls.c:4233: dumping 'input record from network' (7 bytes)

.ssl_tls.c:4233: 0000: 15 03 03 00 02 02 50 ......P

.ssl_tls.c:5170: got an alert message, type: [2:80]

.ssl_tls.c:5178: is a fatal alert message (msg 80)

.ssl_tls.c:4369: mbedtls_ssl_handle_message_type() returned -30592 (-0x7780)

.ssl_cli.c:1506: mbedtls_ssl_read_record() returned -30592 (-0x7780)

Putting the ciphersuites to one side, I suspect that what is happening here is that the (remote) server is complaining about a TLS extension the mbedtls client is either including or omitting. (I’ve already disabled the max fragment extension). But because I can’t see inside the remote server, I can’t tell. ☹

Might the mbedtls TLS client need the supported_versions extension (43) to work with many remote TLS servers?

Is this a known issue? I’ve gone through loads of mailing list archive messages here, but haven’t found anything that matches this.

Thanks, Nick

PS: when OpenSSL connects to the server, the client hello message (that works fine) looks like this in Wireshark:

Transport Layer Security

TLSv1.2 Record Layer: Handshake Protocol: Client Hello

Content Type: Handshake (22)

Version: TLS 1.2 (0x0303)

Length: 358

Handshake Protocol: Client Hello

Handshake Type: Client Hello (1)

Length: 354

Version: TLS 1.2 (0x0303)

Random: [SNIP]

GMT Unix Time: Jan 21, 2095 20:50:07.000000000 GMT Standard Time

Random Bytes: [SNIP]

Session ID Length: 32

Session ID: [SNIP]

Cipher Suites Length: 90

Cipher Suites (45 suites)

[SNIP!]

Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)

Compression Methods Length: 1

Compression Methods (1 method)

Compression Method: null (0)

Extensions Length: 191

Extension: status_request (len=5)

Type: status_request (5)

Length: 5

Certificate Status Type: OCSP (1)

Responder ID list Length: 0

Request Extensions Length: 0

Extension: supported_groups (len=22)

Type: supported_groups (10)

Length: 22

Supported Groups List Length: 20

Supported Groups (10 groups)

Supported Group: x25519 (0x001d)

Supported Group: secp256r1 (0x0017)

Supported Group: secp384r1 (0x0018)

Supported Group: secp521r1 (0x0019)

Supported Group: x448 (0x001e)

Supported Group: ffdhe2048 (0x0100)

Supported Group: ffdhe3072 (0x0101)

Supported Group: ffdhe4096 (0x0102)

Supported Group: ffdhe6144 (0x0103)

Supported Group: ffdhe8192 (0x0104)

Extension: ec_point_formats (len=2)

Type: ec_point_formats (11)

Length: 2

EC point formats Length: 1

Elliptic curves point formats (1)

EC point format: uncompressed (0)

Extension: signature_algorithms (len=34)

Type: signature_algorithms (13)

Length: 34

Signature Hash Algorithms Length: 32

Signature Hash Algorithms (16 algorithms)

[SNIP!]

Extension: signature_algorithms_cert (len=34)

Type: signature_algorithms_cert (50)

Length: 34

Signature Hash Algorithms Length: 32

Signature Hash Algorithms (16 algorithms)

[SNIP!]

Extension: status_request_v2 (len=9)

Type: status_request_v2 (17)

Length: 9

Certificate Status List Length: 7

Certificate Status Type: OCSP Multi (2)

Certificate Status Length: 4

Responder ID list Length: 0

Request Extensions Length: 0

Extension: extended_master_secret (len=0)

Type: extended_master_secret (23)

Length: 0

Extension: supported_versions (len=5)

Type: supported_versions (43)

Length: 5

Supported Versions length: 4

Supported Version: TLS 1.3 (0x0304)

Supported Version: TLS 1.2 (0x0303)

Extension: psk_key_exchange_modes (len=2)

Type: psk_key_exchange_modes (45)

Length: 2

PSK Key Exchange Modes Length: 1

PSK Key Exchange Mode: PSK with (EC)DHE key establishment (psk_dhe_ke) (1)

Extension: key_share (len=38)

Type: key_share (51)

Length: 38

Key Share extension

Client Key Share Length: 36

Key Share Entry: Group: x25519, Key Exchange length: 32

Group: x25519 (29)

Key Exchange Length: 32

Key Exchange: 9f8e83a6859e6b4c6c3e43b524b81e6f63cc409c5757692a2343a2929c681c17