Hi Fabian,

Thank you for using Mbed TLS and for your detailed report.

When mbedtls_ssl_read() returns MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET it signals to the caller that we have received a new session ticket and gives the opportunity to save it for reuse later. An example of how this could be done is in the sample program ssl_client2.c: https://github.com/Mbed-TLS/mbedtls/blob/v4.1.0/programs/ssl/ssl_client2.c#L2661-L2697.

mbedtls_ssl_write() calls mbedtls_ssl_handshake() whenever the handshake state is not MBEDTLS_SSL_HANDSHAKE_OVER and thus in theory still might end up reading data and receiving a new session ticket.

Long story short: MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET is a non-fatal error and it is safe to ignore if you are not using session tickets.

Regards,
Janos


From: Fabian Keil via mbed-tls <mbed-tls@lists.trustedfirmware.org>
Date: Thursday, 23 April 2026 at 06:21
To: mbed-tls@lists.trustedfirmware.org <mbed-tls@lists.trustedfirmware.org>
Subject: [mbed-tls] mbedtls_ssl_read() return code MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET

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#aa2c29eeb1deaf5ad9f01a7515006ede5>
[2]: <https://github.com/Mbed-TLS/mbedtls/issues/6640>