All versions of the Transport Layer Security (TLS) protocol support resuming previously established connections. The keying material previously negotiated is re-used in the new connection. The major benefits of resuming sessions are the much shorter handshake and not having to recompute session keys. In embedded systems, both of these advantages are critical to decrease the latency of a connection. TLS session resumption uses much less bandwidth and fewer clock cycles than a full handshake. There are two methods to resume a TLS session: using the session ID or a session ticket.
The TLS session ID can be used to resume TLS <= 1.2 sessions. It has been deprecated in TLS 1.3 in favor of only tickets. The session ID is sent to the client from the server in the ServerHello message when performing a full handshake. When a client wants to resume a session, it sends the session ID in the ClientHello. The server then needs to find the session matching the ID in its cache and restore the keying material. This requires both sides to store the keying material. This means that servers need to have a cache that grows linearly with the number of peers that it intends to resume with.
TLS session resumption tickets are available in all versions of TLS, although TLS version 1.3 has introduced a few changes. The general idea is that a server can issue an encrypted ticket to the client that contains all of the data necessary to resume a session. The client has to store the ticket and the keying material to be able to resume the session while the server does not have to store anything (apart from the encryption key used to encrypt the ticket). This removes the cache burden on the server entirely. In TLS <= 1.2 the session ticket is sent as part of the handshake while in 1.3 it is a post-handshake message. This means that the server can actually issue multiple tickets in one connection but the client needs to wait until after the handshake for the server to send the ticket before it can resume a session. TLS 1.3 servers usually send the ticket as the first message right after the handshake.
To perform session resumption in wolfSSL, please see the documentation about the wolfSSL_get1_session API.
For more information about session resumption in wolfSSL, or if you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.
Download wolfSSL Now