／var／logmarcus chiu

SSL／TLS - Optimizing Handshaking

Created on

TLS - Full Handshake

full handshake requires 3 round trips:

  • 1 round trip for TCP 3-Way Handshake (note the last TCP ACK message is sent with the first TLS ClientHello message)
  • 2 round trips for TLS cipher-suite choosing, certificate exchange, client-key-exchange, finished message

Optimizing TLS Handshakes

For Starting New Session

  • False Start - send application data right after ChangeCipherSpec message is sent

For Resuming A Session

  • Abbreviated Handshake - https://blogs.msdn.microsoft.com/huizhu/2009/12/17/ssl-tls-full-handshake-vs-abbreviated-handshake/
    • uses 2 mechanisms:
      • session IDs -
      • session tickets -
    • the difference between TLS Full handshake and TLS Abbreviated Handshake is that abbreviated handshake is using 32 bit existing SSL session ID for Client Hello. If SSL server agreed on this session, server doesn’t need to send the public key of certificate back to client. Also, client doesn’t need to take time to validate the server cert as it is an existing session. If server doesn’t agree on the SSL session, server needs to push a new session ID and then go to full handshake.
  • Resumption and Pre-Shared Key (PSK) - https://tools.ietf.org/html/rfc8446#section-2.2
    • introduced in TLS 1.3
    • deprecates TLS Abbreviated Handshake

The combination of both: False Start & Abbreviated Handshake allows us to deliver a consistent 1-RTT TLS handshake for new and returning visitors, plus computational savings for sessions that can be resumed based on previously negotiated session parameters. Make sure to take advantage of these optimizations in your deployments.

NOTE:

One of the design goals for TLS 1.3 is to reduce the latency overhead for setting up the secure connection: 1-RTT for new, and 0-RTT for resumed sessions!

TODO Description

Session Resumption

Description

TLS 1.3
Resumption and Pre-Shared Key (PSK)

Although TLS PSKs can be established out of band, PSKs can also be
established in a previous connection and then used to establish a new
connection (“session resumption” or “resuming” with a PSK). Once a
handshake has completed, the server can send the client a PSK
identity that corresponds to a unique key derived from the initial
handshake (see Section 4.6.1). The client can then use that PSK
identity in future handshakes to negotiate the use of the associated
PSK. If the server accepts the PSK, then the security context of the
new connection is cryptographically tied to the original connection
and the key derived from the initial handshake is used to bootstrap
the cryptographic state instead of a full handshake. In TLS 1.2 and
below, this functionality was provided by “session IDs” and “session
tickets” [RFC5077]. Both mechanisms are obsoleted in TLS 1.3.

PSKs can be used with (EC)DHE key exchange in order to provide
forward secrecy in combination with shared keys, or can be used
alone, at the cost of losing forward secrecy for the application
data

TLS 1.2
”session IDs” and “session tickets”

Two mechanisms can be used to accomplish an abbreviated handshake:

  1. When the server sends the “Server Hello” message, it can include a session identifier. The client should store it and present it in the “Client Hello” message of the next session. If the server finds the corresponding session in its cache and accepts to resume the session, it will send back the same session identifier and will continue with the abbreviated TLS handshake. Otherwise, it will issue a new session identifier and switch to a full handshake. This mechanism is detailed in RFC 5246. It is the most common mechanism because it exists since earlier versions of TLS.
  2. In the last exchange of a full TLS handshake, the server can include a “New Session Ticket” message (not represented in the handshake described in the picture) which will contain the complete session state (including the master secret negotiated between the client and the server and the cipher suite used). Therefore, this state is encrypted and integrity-protected by a key known only by the server. This opaque datum is known as a session ticket. The details lie in RFC 5077 which supersedes RFC 4507.

The ticket mechanism is a TLS extension. The client can advertise its support by sending an empty “Session Ticket” extension in the “Client Hello” message. The server will answer with an empty “Session Ticket” extension in its “Server Hello” message if it supports it. If one of them does not support this extension, they can fallback to the session identifier mechanism built into TLS.

RFC 5077 identifies situations where tickets are desirable over session identifiers. The main improvement is to avoid to maintain a server-side session cache since the whole session state is remembered by the client, not the server. A session cache can be costly in term of memory and difficult to share between multiple hosts when requests are load-balanced across servers.