At wolfSSL we have found more and more customers choosing to use TLS 1.3. That’s great! More businesses are taking advantage of the improved security in the new protocol. These customers are finding that they need to use session tickets for resumption for the first time in their applications. In the latest release of wolfSSL, 4.7.0, we’ve made this easier than ever.
Encryption Algorithm
Session tickets require the implementation of a callback that encrypts and decrypts them on the server. There is a great example of how in wolfssl/test.h. Take a look at myTicketEncCb(). Previously the callback encrypted with ChaCha20-Poly1305 but now we include using AES-GCM instead. Choose the one that suites your application!
Default Encryption Callback
At wolfSSL we decided that a default callback was a valuable addition. wolfSSL 4.7.0 now includes a default session ticket encryption callback. Understanding how it works will inform you as to whether to use the default or write your own.
The callback is encrypting and decrypting the session ticket. You can choose which encryption algorithm to use by defining one of the following:
WOLFSSL_TICKET_ENC_CHACHA20_POLY1305– use ChaCha20-Poly1305WOLFSSL_TICKET_ENC_AES128_GCM– use AES-GCM with 128-bit keyWOLFSSL_TICKET_ENC_AES256_GCM– use AES-GCM with 256-bit key
Otherwise, the default will be ChaCha20-Poly1305. If that algorithm is not compiled in then it will use AES-GCM with a 128-bit key.
There are two keys that are generated in the callback: primary and secondary. The primary key is generated, with a private random number generator, at first use and which point it is given a lifetime. By default, this is one hour. It can be customized at the second resolution by defining WOLFSSL_TICKET_KEY_LIFETIME. The lifetime must be larger than the lifetime of a session ticket which is 5 minutes by default. This too can be changed at the second resolution by defining SESSION_TICKET_HINT_DEFAULT. The longer the key lifetime the longer the exposure time if a key is compromised.
There are two lifetimes for a key: encryption and decryption. A key used to encrypt a ticket must be kept for the life of the ticket. Therefore the encryption lifetime is shorter than the total key lifetime, or decryption lifetime, by the ticket lifetime. See the diagram below:
If the primary key is expired for encryption but not for decryption, i.e is in the shaded area above, then a secondary key is generated on the next encrypt request. See below.
The secondary key is used until it expires for encryption and only then will a new primary key be generated. Note that in the scenario where session tickets are not commonly used, the primary key may expire for decryption before a new call for encryption. In this case, a new primary key will be generated. In a threaded environment, the generation of the global keys are protected by a mutex to ensure no overwriting.
Exporting and importing keys is also possible using: wolfSSL_CTX_get_tlsext_ticket_keys() and wolfSSL_CTX_set_tlsext_ticket_keys(). These APIs are useful for sharing keys across processes or server machines and expiration times are included in the blob.
The default session ticket encryption callback will cover most use cases. If you want to use another encryption algorithm, have very limited memory, or need an advanced sharing strategy between servers then define WOLFSSL_NO_DEF_TICKET_ENC_CB and set your own callback.
TLS 1.3 and TLS 1.2 Session Ticket Use
Finally, customers that haven’t been using session tickets for TLS 1.2 connections and now are for TLS 1.3, wanted to prevent session tickets being used with TLS 1.2. A reasonable request that we now support with the functions:
wolfSSL_CTX_NoTicketTLSv12()
wolfSSL_NoTicketTLSv12()
Calling these functions sets a flag against the context or object that results in the handshake ignoring session tickets on the client and server when the protocol version negotiated is TLS 1.2 or lower.
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.