I'm currently working on adding MbedTLS 4.x support for
Privoxy [0] and noticed that mbedtls_ssl_read() frequently
returns MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET.
Apparently the error code was added in f8a4994ec7 and marked
experimental in da13072c5b.
It doesn't seem explicitly documented at [1], but of course
it's covered by "or another negative error code".
My current solution is to simply continue reading:
extern int ssl_recv_data(struct ssl_attr *ssl_attr, unsigned char *buf, size_t max_length)
{
[...]
do
{
ret = mbedtls_ssl_read(ssl, buf, max_length);
#if MBEDTLS_VERSION_MAJOR > 3
if (ret == MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET)
{
log_error(LOG_LEVEL_CONNECT,
"mbedtls_ssl_read() reported new session ticket for "
"the connection on socket %d.",
ssl_attr->mbedtls_attr.socket_fd.fd);
}
#endif
} while (ret == MBEDTLS_ERR_SSL_WANT_READ
#if MBEDTLS_VERSION_MAJOR > 3
|| ret == MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET
#endif
|| ret == MBEDTLS_ERR_SSL_WANT_WRITE);
When using MbedTLS 4.1.0 on ElectroBSD 14.4-STABLE this seems to work.
For some connections the log message is emitted once, for others
it's emitted twice:
09:20:58.982 024 Connect: Connected to 127.0.1.2[127.0.1.2]:9050.
09:20:59.222 024 Connect: Created new connection to www.electrobsd.org:443 on socket 9.
09:20:59.243 024 Connect: Performing the TLS handshake with the server.
09:20:59.583 024 Connect: Server successfully connected over TLSv1.3 (TLS1-3-CHACHA20-POLY1305-SHA256).
09:20:59.583 024 Connect: Encrypted request sent.
09:20:59.809 024 Connect: mbedtls_ssl_read() reported new session ticket for the connection on socket 9.
09:20:59.902 024 Connect: mbedtls_ssl_read() reported new session ticket for the connection on socket 9.
09:21:00.041 024 Header: scan: HTTP/1.1 200 OK
I noticed that there's already an open ticket [2] which contains
the sentence:
| For client side, mbedtls_ssl_{read,write} might return the error also,
| we should process it in the error handler also.
I haven't seen mbedtls_ssl_write() return MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET
yet, though.
Can you confirm that handling MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET
by continuing reading is currently the best option?
Thanks.
Fabian
[0]: <https://www.privoxy.org/>
[1]: <https://os.mbed.com/teams/sandbox/code/mbedtls/docs/tip/ssl_8h.html#aa2c29e…>
[2]: <https://github.com/Mbed-TLS/mbedtls/issues/6640>
Dear Mbed TLS contributors,
I am working on an embedded project where we need to verify an X509 certificate chain with up to 4 certificates (root cert + 2 intermediates + client cert) and a CRL. The certificates contain public keys for ECDSA for the SECP_R1_256 curve. We are using mbedTLS 4.x.
There is no heap memory in this project. It is a vehicle control ECU and all RAM is normally statically allocated for safety reasons. However, the certificate verification is not safety critical. It is OK for us to use mbedtls_memory_buffer_alloc_init() as a heap replacement for mbedTLS. I will refer to this as the "heap" for the rest of this mail.
I would like to find out how large the heap needs to be for the chain verification. The system requirements state that it shall support certificates and CRL in DER format with a size of up to 2 kB each. There are 10 kB of static RAM buffer to store 4 certificates and the CRL.
The certificates are parsed with mbedtls_x509_crt_parse_der_nocopy(), so the certificate raw data is not duplicated on the heap.
The CRL is parsed with mbedtls_x509_crl_parse_der(), so I am expecting that the CRL raw data will be copied to the heap. Thus, it needs to be at least 2 kB. Unfortunately, there seems to be no "_nocopy()" function for CRLs.
8 kB heap was enough in my tests to verify a chain of 3 test certificates with sizes of ca. 0.5 kB each. 6 kB heap wasn't enough to do this.
Is there a way to calculate or at least estimate the maximum required heap for the given maximum certificate and CRL sizes, such that a call of mbedtls_x509_crt_verify() for the chain will never fail due to insufficient memory?
Is the required heap size fixed for a given number of certificates, or does it depend on the content of the certificates? If it does depend on the content, is there some way to construct "worst case certificates" that result in maximum heap usage, so I could use them to measure the heap consumption?
Any help on this topic is kindly appreciated!
Best regards,
Ralf Huber
KION Supply Chain Solutions
Linde Material Handling GmbH,
Sitz der Gesellschaft: Aschaffenburg, Registergericht: Aschaffenburg HRB9963, Ust-IdNr. DE814809128, Gesch?ftsf?hrung: Andreas Krinninger (Vorsitzender), Dr. Karoline Jung-Senssfelder, Ulrike Just, Dr. Frank Schepp, Vorsitzende des Aufsichtsrats: Valeria Gargiulo
Dear MbedTLS team,
I maintain the Mbed TLS integration for our embedded products. We are still migrating from Mbed TLS 2.x to 3.6.x and need guidance on replacing the legacy SSL key export behavior.
One of our legacy products utilizes handshake key material from mbedtls_ssl_conf_export_keys_cb in an accelerator. For compatibility with existing deployments, we must preserve this key export so the other side can decode.
Section “SSL key export interface change” in 3.0-migration-guide.md (as referenced for the 3.6.x line) states that mbedtls_ssl_conf_export_keys_cb() and mbedtls_ssl_conf_export_keys_ext_cb() were replaced with mbedtls_ssl_set_export_keys_cb(), and that the new callback no longer exports raw keys and IV. The guide suggests that applications requiring raw traffic keys may derive them from the master secret and handshake transcript hashes from the on-wire data. I'm not sure how this can be coded. What is the recommended way to obtain or derive the raw keys and IV (or equivalent data) under the 3.6.x API? Could you point to documentation, examples of code would be very beneficial.
We would also like to align with the 4.1.x in future. If there are changes in this area, we are interested in a common and supported approach to avoid repeated breaking migrations.
Thank you for your time.
Kind regards,
Piotr
