TLS 1.3, the latest version of the TLS protocol published in August 2018 by the IETF (RFC 8446) has a great future ahead of it. It meets the current needs of “full https”, which is widely adopted by web giants, while offering better performance and security than TLS 1.2.

Increasing numbers of web servers and web browsers are offering updates which are compatible with this version. In a few years’ time, TLS 1.3 will no doubt be the predominant communication security protocol. Let’s take a look at the improvements and new features of TLS 1.3.

TLS is the most widespread protocol for securing communications among different IT systems. It guarantees:

• Authenticity: the identity of the communicating parties is authenticated
• Integrity: the exchanged data is only visible to the participants
• Integrity: the transmitted data can’t be compromised by malicious parties

TLS 1.3: enhanced security

These days, enabling the TLS 1.2 protocol isn’t enough to guarantee secure communication. It accepts several cryptographic algorithms that are now obsolete such as SHA-1, RC4, DES, 3DES, AES-CBC, MD5 and Diffie-Hellman groups. Incorrect server configuration in terms of choice of algorithms could enable malicious attacks.

TLS 1.3 disables or improves the obsolete algorithms accepted by TLS 1.2 and includes new algorithms to only propose AEAD (Authenticated Encryption with Associated Data) cipher suites, which is a form of encryption ensuring data confidentiality and authenticity.

The new version of the protocol also offers an alternative to algorithms supported by NIST, which was implicated in the deliberate weakening of cryptographic systems following its relationship with the NSA. Version 1.3 provides the option of using algorithms designed by D. J. Bernstein (EdDSA, ChaCha20, x25519 among others), standard algorithms (such as AES or ECDSA) and NIST curves (P-256, P-384, P-512, etc.).

Key derivation algorithms are also changing. The previous version uses a pseudorandom function (PRF) whereas in TLS 1.3, keys are generated with HKDF (extract and expand), an HMAC-based key derivation function.

The update also introduces changes relating to key exchange mechanisms. Perfect Forward Secrecy (PFS) is now mandatory. TLS 1.2 required additional parameters to implement this functionality. PFS is a property which guarantees that the confidentiality of past communications is not compromised if an adversary discovers a correspondent’s private key. This choice was greatly criticized by governments and some companies who are strongly opposed to this new version which makes monitoring more difficult.

Another major change in the protocol is the new design of the TLS Handshake. With TLS 1.2, the first part of this phase, cipher suite negotiation, is unencrypted, leaving it open to “downgrade” attacks during which attackers force the use of weak algorithms. Similarly, extensions sent in the ServerHello message (see Handshake diagram) are unencrypted. With TLS 1.3, the server signs all the messages transmitted during the handshake, including algorithm negotiation and all the messages sent after the ServerHello, and all the extensions are encrypted.

This new way of operating, combined with the ESNI (Encrypted Server Name Indication) extension, prevents third-party observers from detecting which website a user is trying to access. This effectively prevents monitoring tools from seeing what Internet users are doing online and some governments have even blocked the use of TLS.

TLS 1.3 is faster

TLS 1.2 needs at least two round trips, not counting SYN, SYN-ACK messages, to finalize the handshake and establish the secure channel. TLS 1.3 only requires a single round trip, speeding up the connection as shown below:

In the first call, the client sends the ClientHello message to the server. It contains:

• The nonce (random number to prevent replay attacks)
• The TLS protocol version used
• The list of supported symmetric algorithms and HKDF
• And either a set of Diffie-Hellman shared keys or a set of pre-shared key labels or a both at the same time

The client can also send the list of required extensions.                                                                                                          

The server processes the ClientHello message and determines the appropriate cryptographic parameters for the connection.

The server then replies with a ServerHello indicating the negotiated connection parameters:

• If Diffie-Hellman keys are used for the key exchange, the ServerHello message replies with the “key share” extension with the server’s Diffie-Hellman shared key.
• If pre-shared keys are used for the key exchange, the ServerHello message replies with the “pre_shared_key” extension indicating the pre-shared key label to use.
• The two modes can also be used at the same time.

The server can send two additional messages in response to the extensions requested by the client, and to request client authentication.

The server then sends its certificate (but other authentication methods can be defined such as PSK) and a signature of all the previous exchanges with the private key associated with the server certificate (CertificateVerify).

Finally, the exchange ends with “finished”, which is a MAC (Message Authentication Code) calculation for the whole handshake.

End of handshake:

The client can send its certificate and the handshake signature with its private key (CertificateVerify) if requested by the server, and ends the exchange with a “finished” message containing a MAC calculation for the whole handshake.

Key:

*: optional

[]: encrypted

NB: this diagram shows the nominal case where the data sent by the client is accepted by the server on the first exchange (shared keys among others). If this is not the case, the server can send additional messages asking the client to provide the supported elements.

Zero Round Trip Time: even faster connections

The Zero Round Trip Time (0-RTT) feature can be enabled to further speed up connections. As its name indicates, the handshake requires no round trips.

When a client and server share a pre-shared key which has been manually imported or calculated during a previous handshake, TLS 1.3 enables the client to send application data on the first flight. This is known as early data. The pre-shared key is used to authenticate the server and encrypt the data sent on the first flight.

However, this feature does have a weakness as it’s vulnerable to replay attack where an attacker intercepts the first message and resends it, pretending to be a client. Fortunately, this function is not enabled by default.

The TLS protocol has become essential for securing connections and with it, the digital certificates have become necessary for its proper functioning. These certificates have a limited lifespan and in order to keep a secured connection and avoid outages, one needs to learn to manage them. Over the years, the restrictions and the numbers of certificates have been increasing, making this task more and more difficult for operational security teams.

Our BerryCert solution can identify all the certificates in the information systems and manage and automatically renew them to minimize the risk of similar incidents.