Arm Mbed and Pelion Device Management support forum

Mbed TLS and lwip as web server

I am having a problem trying to get mbed tls to work with lwip for web server. It does not look like Chrome an TLS can agree upon an algorithm error -6980. Any hints on the root cause?

httpd.c 2789: http_accept 204542f0 / 0
ssl_tls.c 8086: => handshake
ssl_srv.c 4261: server state: 0
ssl_tls.c 2757: => flush output
ssl_tls.c 2769: <= flush output
ssl_srv.c 4261: server state: 1
ssl_tls.c 2757: => flush output
ssl_tls.c 2769: <= flush output
ssl_srv.c 1213: => parse client hello
ssl_tls.c 2538: => fetch input
ssl_tls.c 2699: in_left: 0, nb_want: 5
ssl_tls.c 2723: in_left: 0, nb_want: 5
ssl_tls.c 2744: <= fetch input
ssl_srv.c 1257: client hello v3, message type: 22
ssl_srv.c 1266: client hello v3, message len.: 512
ssl_srv.c 1269: client hello v3, protocol version: [3:1]
ssl_tls.c 2538: => fetch input
ssl_tls.c 2699: in_left: 5, nb_want: 517
ssl_tls.c 2723: in_left: 5, nb_want: 517
ssl_tls.c 2744: <= fetch input
ssl_srv.c 1369: client hello v3, handshake type: 1
ssl_srv.c 1378: client hello v3, handshake len.: 508
ssl_srv.c 1830: unknown extension found: 51914 (ignoring)
ssl_srv.c 1830: unknown extension found: 23 (ignoring)
ssl_srv.c 1713: found renegotiation extension
ssl_srv.c 1740: found supported elliptic curves extension
ssl_srv.c 1748: found supported point formats extension
ssl_srv.c 377: point format selected: 0
ssl_srv.c 1830: unknown extension found: 35 (ignoring)
ssl_srv.c 1830: unknown extension found: 16 (ignoring)
ssl_srv.c 1830: unknown extension found: 5 (ignoring)
ssl_srv.c 1726: found signature_algorithms extension
ssl_srv.c 267: client hello v3, signature_algorithm ext: match sig 4 and hash 6
ssl_srv.c 249: client hello v3, signature_algorithm ext unknown sig alg encoding 4
ssl_srv.c 267: client hello v3, signature_algorithm ext: match sig 1 and hash 6
ssl_srv.c 267: client hello v3, signature_algorithm ext: match sig 4 and hash 7
ssl_srv.c 249: client hello v3, signature_algorithm ext unknown sig alg encoding 5
ssl_srv.c 267: client hello v3, signature_algorithm ext: match sig 1 and hash 7
ssl_srv.c 249: client hello v3, signature_algorithm ext unknown sig alg encoding 6
ssl_srv.c 267: client hello v3, signature_algorithm ext: match sig 1 and hash 8
ssl_srv.c 272: client hello v3, signature_algorithm ext: hash alg 4 not supported
ssl_srv.c 1830: unknown extension found: 18 (ignoring)
ssl_srv.c 1830: unknown extension found: 51 (ignoring)
ssl_srv.c 1830: unknown extension found: 45 (ignoring)
ssl_srv.c 1830: unknown extension found: 43 (ignoring)
ssl_srv.c 1830: unknown extension found: 27 (ignoring)
ssl_srv.c 1830: unknown extension found: 19018 (ignoring)
ssl_srv.c 1830: unknown extension found: 21 (ignoring)
ssl_srv.c 822: trying ciphersuite: TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
ssl_srv.c 720: ciphersuite requires certificate
ssl_srv.c 735: certificate mismatch: key type
ssl_srv.c 911: ciphersuite mismatch: no suitable certificate
ssl_srv.c 822: trying ciphersuite: TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
ssl_srv.c 720: ciphersuite requires certificate
ssl_srv.c 735: certificate mismatch: key type
ssl_srv.c 911: ciphersuite mismatch: no suitable certificate
ssl_srv.c 1987: got ciphersuites in common, but none of them usable
ssl_tls.c 5252: => send alert message
ssl_tls.c 5253: send alert level=2 message=40
ssl_tls.c 3345: => write record
ssl_tls.c 3425: output record: msgtype = 21, version = [3:3], msglen = 2
ssl_tls.c 2757: => flush output
ssl_tls.c 2776: message length: 7, out_left: 7
ssl_tls.c 2809: <= flush output
ssl_tls.c 3478: <= write record
ssl_tls.c 5265: <= send alert message
ssl_tls.c 8096: <= handshake
altcp_tls_mbedtls.c 283: mbedtls_ssl_handshake failed: -0x6980

HI @trampas
Thank you for your query.
Since you haven’t mentioned what Mbed TLS version you are using, I will answer according to our latest LTS branch ( mbedtls-2.16) .
Your logs indicate the cause for the failure:

ssl_srv.c 822: trying ciphersuite: TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
ssl_srv.c 720: ciphersuite requires certificate
ssl_srv.c 735: certificate mismatch: key type
ssl_srv.c 911: ciphersuite mismatch: no suitable certificate
ssl_srv.c 822: trying ciphersuite: TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
ssl_srv.c 720: ciphersuite requires certificate
ssl_srv.c 735: certificate mismatch: key type
ssl_srv.c 911: ciphersuite mismatch: no suitable certificate
ssl_srv.c 1987: got ciphersuites in common, but none of them usable

This is because the certificates you have set as your server certificates cannot be used for the certificate verification, as they do not match the common ciphersuites.

You see in the logs that both the common ciphersuites this log. THis is because the certificate that is set does not meet the ciphersuites required for ECDHE key exchange and ECDSA certificate verification. Is your server certificate only RSA signed?

Note: I also see in the log that you have many unknown extensions, some of them are because they are disabled in your project. I assume you are aware of this though.

Regards,
Mbed Support
Ron

Thanks I found out that RSA keys are not supported in chrome and needed to generate the keys using:

openssl ecparam -genkey -name prime256v1 -out ca.key
openssl req -x509 -new -SHA256 -nodes -key ca.key -days 3650 -out ca.crt

I noticed some extensions were not enabled, but was not sure if they needed to be?

Thanks
Trampas

HI @trampas
Regarding supporting the extensions, it is up to you to decide what extensions you wish to support and what you do not.
For this specific session, none of the unknokwn extensions are critical extensions, so there shouldn’t be an issue
Regards

Thanks…

I have been debugging my problems and found that mbedtls is allocating 176k from heap. I still find that communications is not reliable using lwip and mbedtls. I have 384k SRAM on the processor and I am not overflowing heap. However it appears that quite often I am getting:
ERROR: ssl_tls.c 5180: is a fatal alert message (msg 46)
ERROR: altcp_tls_mbedtls.c 283: mbedtls_ssl_handshake failed: -0x7780

I am using mbedtls 2.16.4 and lwip 2.1.2 if it make a difference.

Trampas

Hi @trampas

This means that the remote peer couldn’t handle the message that your peer has sent and aborted the the connection. Fatal alerts have an additional message stating the reason for the alert. You should also look after what message that your peer has sent the remote peer has sent the fatal alert, to give you hints on what could be the misalignment between the two peers. For example, if the server sends this message after the client sent the client hello (like in the original post), then it means that the server could not find a common ciphersuite or certificate, etc…
Regards