Changes coming to TLS: Part One

This article was originally published on the Red Hat Customer Portal. The information may no longer be current.

Transport layer Security version 1.3 (TLS 1.3) is the latest version of the SSL/TLS protocol which is currently under development by the IETF. It offers several security and performance improvements as compared to the previous versions. While there are several technical resouces which discuss the finer aspects of this new protocol, this two-part article is a quick reference to new features and major changes in the TLS protocol.

Faster Handshakes

In TLS, before data can be encrypted, a secure channel needs to created. This is achieved via the handshake protocol in which a cipher suite is negotiated between the client and the server and key share materials are exchanged.

The handshake is initiated by the TLS client utilizing a ClientHello message sent to the server. This message contains, among other things, a list of cipher suites which the client is capable of supporting. The server replies to this message in its ServerHello message by picking one of the cipher suites from the client list and, along with it, the server also sends its key share and the site's certificate to the client.

The client receives all of the above, generates its own key share, combines it with the server key share and generates bulk encryption keys for the session. The client then sends the server its key share and sends a FINISHED message which contains a signed hash of all the data which was previously exchanged. The server does the same thing by sending its own FINISHED message.

This ends the handshake and results in a cipher suite and a bulk encryption key being negotiated between the client and the server and takes two full rounds of data exchange.1

TLS 1.3 aims to make this faster by reducing the handshake to just one round trip (1-RTT). In TLS 1.3 the ClientHello not only contains a list of supported ciphers, but also it makes a guess as to what key agreement protocol the server is likely to chose and sends a key share for that particular protocol.

As soon as the server selects the key agreement protocol it sends its own key share and, at the same time, generates the bulk encryption key (since it already has the client key share). In doing so, the computers can switch to encrypted messages one whole round trip in advance. The ServerHello also contains the FINISHED message. The client receives the server key share, generates bulk encryption keys, sends the FINISHED message and is immediately ready to send encrypted data. This results in faster handshakes and better performance.2

Faster Session Resumptions

The TLS protocol has a provision for session resumption. The general idea is to avoid a full handshake by storing the secret information of previous sessions and reusing those when connecting to a host the next time. This drastically reduces latency and CPU usage. However in modern times the session resumption is usually frowned upon because it can easily compromise Perfect Forward Secrecy (PFS).

Session resumption can be achieved in one of the two following ways:

1. Session ID:
   In a full handshake the server sends a Session ID as part of the ServerHello message. On a subsequent connection the client can use this session ID and pass it to the server when connecting. Because both server and client have saved the last session’s “secret state” under the session ID they can simply resume the TLS session where they left off.

2. Session Tickets:
   The second mechanism to resume a TLS session are Session Tickets. This extension transmits the server’s secret state to the client, encrypted with a key only known to the server. That ticket key is protecting the TLS connection now and in the future and is the weak spot an attacker will target. The client will store its secret information for a TLS session along with the ticket received from the server. By transmitting that ticket back to the server at the beginning of the next TLS connection both parties can resume their previous session, given that the server can still access the secret key that was used to encrypt it.

In both of the above methods session resumption is done by using 1-RTT (one round trip). However TLS 1.3 achieves this by using 0-RTT. When a TLS 1.3 client connects to a server, they agree on a session resumption key. If pre-shared keys (PSK) are used the server provides a Session Ticket which can be encrypted using the PSK if required.

During Session resumption, the client sends the Session Ticket in the ClientHello and then immediately, without waiting for the RTT to complete, sends the encrypted data. The server figures out the PSK from the session ticket and uses it to decrypt the data and resume the connection. The client may also send a key share, so that the server and the client can switch to a fresh bulk encryption key for the rest of the session.

There are two possible problems with the above implementation though:

1. No PFS when using Session Resumption:
   Since the PSK is not agreed upon using fresh Diffie Hellman, it does not provide Forward Secrecy against a compromise of the session key. This problem can be solved by rotating the session keys regularly.

2. This can easily lead to replay attacks:
   Since the 0-RTT data does not have any state information associated with it, an attacker could easily resend the 0-RTT message, and the server will decrypt the associated data and act on the data it received. One way to avoid this is to make sure that the server does not perform any "important action" (like transferring secret information or making a financial transaction) based on the 0-RTT data alone. For such operations servers can impose 1-RTT session resumptions.

DTLS has an additional concern: during re-handshake it is not known whether the peer is alive at all. Data sent along with the handshake message may have ended up in a black hole, going no where.

Part 2 of the blog discusses the various cryptographic changes found in TLS 1.3 and their implications.