altcp_tls_create_config_client_2wayauth as a lwip function, there is not much I can help on that matter. However, do you really need this function? Can’t you just use the Mbed TLS functions:
mbedtls_ssl_conf_own_cert() ? What’s the added value of using the LwIP function?
The LwIP function
altcp_tls_create_config_client_2wayauth really calls mbedTLS functions
mbedtls_ssl_conf_own_cert(). I don’t think there’s much improvement here if I call mbedTLS functions directly.
LwIP includes an adaptation layer between its TCP/IP stack and mbedTLS library that is named altcp_tls_mbedtls and I’m using it.
Do you happen to know what modules utilize the heap?
Parsing certificates and initial setup, 6kB.
Connection 8+2kB (input and output buffer).
Handshake: mbed_ssl_parse_certificate (10kB); ssl_parse_server_key_exchange (6kB); ssl_write_client_key_exchange (13kB); a few other kilobytes…
I’m using static buffer for calloc. The measures of allocation requirements above are made reading the greatest pointer returned by calloc respect the last greatest pointer returned.
As you can see from this PR, we are working on reducing RAM usage, specifically in the x509 module.
Yes, I hope this can be improved. I was thinking at another solution. Why not creating a tool that “converts” certificate to a binary blob that can be linked in the program, so going in Flash and not RAM? This binary blob should be the same result of run-time parsing of the certificate. In this case, at run-time we “attach” the binary blob as the certificate, we don’t need the original certificate.
If you use ECDSA instead of RSA, The certificate message would be smaller ( perhaps even 4096 would be enough), and probably the RAM usage during handshake would be smaller as well, as certificates signed with ECDSA instead of RSA are significantly smaller, with same security strength.
I tried to enable only
MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, but the server replies with a fatal error immediately after the Client Hello message. It seems the server doesn’t support this ciphersuite, however here Amazon says it supports this (I tried to ask in their forum, but without an answer until now).
So I enable
At the moment I’m using AWS-generated certificates for the client, and they use RSA. I know it’s possible to use personal certificate, however I didn’t checked yet.
The CA root certificates for AWS server authentication are here. As you can see, Amazon CA Root are RSA or ECC based certificate. I’m using RSA. I tried to use ECC-based certificates, but the handshake fails in
mbedtls_x509_crt_verify_restartable. I don’t know whay, it seems flags aren’t zero at the end of the function, so the error code MBEDTLS_ERR_X509_CERT_VERIFY_FAILED is raised.
I compared RSA CA1 and ECC CA3 with MBEDTLS_SSL_VERIFY_NONE and the difference in the heap allocation after successful connection is aroung 1kB.
Are you using your certificates in PEM or DER format?
I was using PER encoded certificates. After your question, I tried to convert PEM to DER certificates. I didn’t notice big differences in RAM allocation during parsing in TLS connection setup. I observed only around 30 bytes difference.