One of the main drawbacks of HTTPS is the time it takes to set up a connection. Specifically, every new TLS connection requires a handshake in order to establish shared encryption keys. This handshake requires two extra round trips on top of the standard TCP handshake roundtrip. On a high-latency connection, waiting for three roundtrips before the first byte is be transferred can make sites appear to load slowly.

tls-image02
A TLS handshake.

TLS has several features that can be used to eliminate round trips during when resuming a session. The two standardized session resumption mechanisms are session IDs (RFC 5246) and session tickets (RFC 5077). Using either technique, a client can resume a previously established a session with a server using an abbreviated handshake, saving one round trip.

Session resumption based on session ID is available in all modern browsers. Both Firefox and Chrome also support session tickets. Support on the server side is also widespread, with nginx, Apache, HAProxy, IIS and others supporting both session IDs and session tickets natively.

Session ID resumption

Resuming an encrypted session is easy if both client and server keep the session keys around. By giving every connection a unique identifier, the server can know if an incoming connection has been seen before. If the server still has the session keys used in that session, it can be resumed.

tls-image01
An abbreviated handshake with session ID resumption

Session IDs require the server to keep the session state (i.e. the session keys) ready in case a previous session needs to be resumed. This requires the server to store a lot of state information, which can require significant amounts of memory.

Session ID sharing is available in Apache through the SSLSessionCache directive and nginx through the ssl_session_cache directive.

Session ticket resumption

In session ticket resumption, the server doesn’t have to store state information for every session it has ever created. Instead, it saves the state in a blob of data and gives it to the client to maintain. Session tickets allow the server to outsource the storage of some of its state to clients, similar to the way HTTP cookies are sometimes used for authentication information.

A session ticket is an encrypted blob of data containing the information needed to resume a TLS connection (i.e. the session keys). It is typically encrypted with a “ticket key” known only to the server. The server sends a session ticket to the client during the initial handshake for it to store locally. When resuming a session, the client sends the session ticket back to the server which decrypts it and resumes the session.

tls-image00
An abbreviated handshake with session ticket resumption

Security Considerations of Session Tickets

If session tickets are implemented improperly there is a potential security downside. Some TLS cipher suites (such as ECDHE-RSA-AES128-SHA256) offer a security property called forward secrecy. If an attacker gets access to a server’s certificate private key, they can’t take past conversations and decrypt them.

With TLS session tickets, stealing the ticket key does allow an attacker to decrypt previous conversations. This makes the ticket key a very valuable key, and using the same key for too long compromises forward security. To keep forward security, ticket keys should be rotated often.

Session ticket resumption is available in Apache through the SSLTicketKeyDefault directive and nginx through the ssl_session_tickets directive. There is no automated way to rotate ticket keys at the moment, but restarting your Apache or nginx instance will cause it to either reload the key from disk or create a new random key.

Load balancing

One of the challenges faced when using these techniques at scale is load balancing. For one server to resume a connection, it needs the key from the previous session. If the previous session was on a different server, the new server needs to get the original session keys somehow.

The approach to this problem taken by both CloudFlare and Twitter is to use a centralized key generation system. Ticket keys are created in a centralized location on a fixed schedule and securely distributed to all the servers used to load balance TLS connections. Implementing session ticket sharing requires a custom system tailored to your architecture.

Conclusions

Reducing the number of roundtrips necessary to establish a connection makes sites appear to load more quickly. For sites using HTTPS, session resumption can be used to improve connection establishment times for returning visitors on all browsers. When implemented correctly, they can provide a noticeable improvement to page load times, even in load-balanced environments.

ABOUT THE AUTHOR

Nick Sullivan (@grittygrease) leads the security engineering team at CloudFlare. He built many of the content security mechanisms for Apple's multi-billion dollar iTunes store. He previously worked as a security analyst worked at Symantec analyzing large scale threat data.