Why do we need TLS 1.3?

A Brief History of TLS

TLS (Transport Layer Security) is a protocol that provides secure communication at the application layer of the OSI Network Model. It essentially provides three main functions – confidentiality, repudiation and data integrity between two parties communicating over the internet. It has two parts – (a) the record protocol which provides confidentiality using symmetric encryption and integrity using HMAC, and (b) the handshake protocol allows two parties to authenticate and negotiate on a shared secret using which the record protocol would work on. Different application layer protocols can leverage the TLS protocols to provide security, e.g. HTTP, SMTP, POP3, FTP etc.

The IETF (Internet Engineering Task Force) oversees designing the TLS protocol. The first version of TLS, known as SSL (Secure Socket Layer) was introduced by Netscape on 1994. The version 1.0 of SSL was never released as it has some serious flaws, and so the first released version of SSL was version 2.0 in 1995. A year later in November 1996, a new draft of SSL was release which mitigates the flaws of SSL 2.0 and was named as SSL 3.0. SSL 2.0 existed longer after v3.0 came out due to backward compatibility, and finally, IETF deprecated SSL 2.0 in 2011. On the year 1999, a new version of SSL was released, but this time it was renamed as TLS (Transport Layer Security) and was called as TLS 1.0. So, essentially SSL 3.1 is TLS 1.0. Due to backward compatibility, SSL 3.0 continued to exist, and eventually in 2015 IETF also deprecated SSL 3.0. TLS 1.1 which was released in April 2006, was more like a sub-version of 1.0 and didn’t had a lot of improvements. After a few years, TLS 1.2 was released on August 2008. But the support of 1.2 came much later, e.g. internet explorer started supporting 1.2 on 2013. Much of the internet is currently running on TLS 1.2, TLS 1.1 and TLS 1.0. Very recently, in August 2018, TLS 1.3 was released to the public, which took care of some serious attacks on TLS 1.2. And it is highly recommended that the internet slowly tries to make the move to TLS 1.3. A lot of providers are looking at deprecating the older version of TLS, i.e. 1.0 and 1.1, and making TLS 1.2 as the bare minimum.

How TLS 1.2 Handshake Works

The TLS 1.2 handshake is a 3-step process, and at the end of the process, two parties trying to communicate would establish a shared cryptographic secure key to encrypt the traffic to achieve confidentiality. During the handshake process, the protocol uses asymmetric encryption for confidentiality and identification (aka digital signature) to exchange the data needed to establish the key. As we all know, the artifact to encapsulate the asymmetric key pair is an X.509 certificate, and so it plays a pivotal role in the protocol. The handshake process is the first process of a TLS connection and would be performed before any data is transferred.  Here are the steps to negotiate and establish the shared key, which will be used for further communication, as defined in the TLS record phase.

1. Initialization Phase: The PartyA (client) sends a client_hello message to PartyB (server). It sends few additional information, e.g. the highest version understood by the client, the list of cipher suites understood by the client, the session id and a random number. The server responds back with a server_hello message with the same parameters. The session id, if sent by the client would be sent back as is (to protect from replay attack), the server would generate a new random number, the selected CipherSuite by the server. This process establishes the connection and other security properties e.g. cryptographic algorithms to use for key exchange, encryption, hashing, and digital signature. We would talk about CipherSuite more in a below section. There are three basic standard key exchange algorithms used here – RSA, Diffie-Hellman, and ECDH. Next, the server sends its X.509 certificate containing its public key. Since the certificate needs to be authenticated by the client, it may send an additional chain of X.509 for validation (containing both the leaf and the intermediate certificates). As part of the verification, the client checks if the certificate is signed by a known trusted CA and is not expired. The server also sends “server_hello_done” message to indicate that it has sent all the information to complete the initialization process.
2. Client Key Exchange Phase: The client computes a “pre-master key” and encrypts it with the server public key (this might differ based on the key exchange algorithm selected above). Then the client sends the encrypted pre-master key to the server, along with its own certificate (optional) if it requires client authentication. The server decrypts the pre-master key with its private key. Now both the client and the server have a pre-master key, using which they can compute the cryptographic session keys.
3. Change Cipher Spec Phase: The client then sends the change_cipher_spec and the encrypted “finished” message to the server, and the server relays backs the change_cipher_spec and encrypted finished message to the client. This message signifies that the server and the client can encrypt and decrypt the messages, and from then on, all the communication would happen in an encrypted connection using the session key generated from the shared pre-master key.

TLS Cipher Suites

As mentioned above in the TLS 1.2 hand-shake steps, a cipher suite is a set of cryptographic algorithms that are used by the client and the server to encrypt, hash and digitally sign messages. In the initialization step of the handshake, the client publishes a set of cipher suites to the server, and the server would select one from the list that it supports. Then the rest of the protocol would use the selected cipher suites algorithms for communications. A typical cipher suite list sent by the client looks like this:

Now let’s take an example and break it apart to understand what it means:

E.g.: TLS_RSA_WITH_AES_256_CBC_SHA

• TLS = defines the protocol this cipher suites would be used for, mostly it would TLS.
• RSA = the key exchange algorithm used (e.g. RSA, Diffie-Helmen, ECDH etc.)
• AES_256_CBC = it’s the encryption algorithm, i.e. AES with 256 bits key in CBC mode. It could be a block cipher algorithm like AES, 3DES or a stream cipher algorithm like RC4.
• SHA = the hashing algorithm (e.g. SHA, MD5 etc.)

Sometimes the key exchange algorithm is also mentioned.

E.g.: TLS_ECDHE_RSA_WITH_RC4_128_SHA

In the above example, the key exchange algorithm is Elliptic curve Diffie-Hellman Exchange (ECDHE), which uses RSA for digital signature.

How TLS 1.3 Handshake Works

One of the major advantages of TLS 1.3 over TLS 1.2 is the condensed and simplified handshake protocol. TLS 1.2 handshake protocol was a 3-step process, whereas TLS 1.3 is a 2-step process. Here is the sequence of events:

1. Step 1: Like TLS 1.2, the TLS 1.3 would start with a “client_hello” message and sends the usual cipher suite list and other details. It does one additional thing here, it “guesses” what algorithm the server is most likely to select and sends the appropriate “pre-master key” for that. The server responds back with “sever_hello” message with the selected cipher suite, along with its server X.509 certificate and the “server_finished” message.
2. Step 2: The client validates the server X.509 certificate, generate session keys based on the pre-master key, and sends the “client_finished” message to the server. At this point, both the client and the server has established the session key, and they would communicate through the secure connection.

This way, TLS 1.3 saves an entire round-trip from the client to the server, which would save hundreds of milliseconds per connection. Additionally, it supports 0-RTT Resumption, which means if the client has talked to the server before, it can establish a secure connection with the server with zero round trip using the pre-shared key (PSK), which provides significant performance improvements.

Improvement of TLS 1.3

There are significant improvements of TLS 1.3 over TLS 1.2, and here is a short list. The full comprehensive list can be found in the TLS 1.3 RFC.

1. Performance improvements in the handshake protocol as described above, by condensing the rounds trips and using 0-RTT resumption.
2. Improved security by deprecating older algorithms like SHA-1, RC4, MD5, 3DES, and AES-CBC.
3. Mandating perfect forward secrecy(more in below section) using ephemeral keys using ECDH key agreement.
4. Dropping support for insecure features like compression (more in the below section).
5. Prohibiting SSL or RC4 negotiations.
6. Adding new and more secure algorithms like ChaCha20, Poly1305, Ed25519 etc. An example of a secure TLS 1.3 cipher suites is – ECDHE-ECDSA-CHACHA20-POLY1305-SHA256. Some of these new algorithms (e.g. ChaCha20 and Poly1305) perform far better on CPU compared to AES for low powered devices like IoT devices.
7. Support of encrypted SNI (Server Name Indication).
8. Protection against protocol downgrade attacks.

Server Name Indication (SNI)

SNI is an extension of TLS, using which the client can indicate the server hostname it needs to connect during the handshake process. This enables the server to host multiple HTTPS websites or other services on TLS with individual certificates on the same IP address and TCP port. This SNI record during the handshake process is not encrypted, so an attacker can view which host is being requested by the client. This leaks important information which can be used by the attacker to mount an attack. With TLS 1.3, an update of this was introduced which enabled it to encrypt the SNI record. It is named as Encrypted SNI (ESNI).

Encryption and Compression

TLS 1.2 and the earlier versions traditionally supported data compression before encryption, and this led to some serious attacks on the TLS protocol. In the client_hello and the server_hello initialization step, the client can specify the compression parameters. When compression is used, it is applied to all the subsequent requests including the header. Compression allows an attacker who can control part of the encrypted message to reveal things about the other parts. A common example is a cookie, which has a standard format, e.g. Cookie: dGhpcyBpcyBhIGNvb2tpZQ, where the prefix – Cookie: is constant.

Use of compression along with encryption would enable significant security vulnerability to TLS, and two of the most common examples are CRIME and BREACH attacks. TLS 1.3 has dropped its support for compression.

Perfect Forward Secrecy

In cryptography, perfect forward secrecy is a feature which guarantees that the session keys generated during key agreement is not compromised, even though the server private key is compromised. For example, the client and the server perform a handshake using standard Diffie-Hellman and agrees on a long-lived key. Then they use that key to encrypt all subsequent communications. An attacker, even though cannot decrypt the message, records them. Later if the attacker manages to break into the server and steals the private key, it would be able to decrypt all the previous messages it has recorded. Implemented a perfect forward secret would stop this, by ensuring there is no long-lived key, and each message is encrypted with an ephemeral one-time use key. TLS 1.2 did support standard Diffie-Hellman key agreement algorithm (i.e. DHE-RSA and DHE-DSA), which never generates ephemeral keys, and uses the long-lived key generated during the initial handshake to encrypt all subsequent messages of the communication. It has support of additional algorithms which provided perfect forward secrecy but was not enforced. TLS 1.3 uses these algorithms as their preferred key exchange algorithms. Some of the key exchange algorithms that provide this capability are – Elliptic curve Diffie–Hellman key exchange (ECDHE-RSA, ECDHE-ECDSA).

But it is imperative to point that, using the 0-RTT Resumption capability of TLS 1.3 would affect its perfect forward secrecy property since it is based on a pre-shared long-lived key.

Fallback Signaling Cipher Suite Value (SCSV)

For backward support, most of the legacy server does not only rely on the TLS version provided by the client during the handshake. So, if the initial handshake attempt fails, the server would auto downgrade the TLS version to a much lower version, e.g. TLS 1.0 or even SSL 3.0. While such downgrade can provide a more consistent connection, but it has serious security implication as the downgraded connection would have serious known vulnerabilities, which could compromise the traffic. In fact, there are many attacks (e.g. FREAK, LogJam etc.), where an attacker can simulate a failure and trick the server to downgrade to a vulnerable version. To mitigate this issue, as part of RFC 7505, a new TLS cipher suite value was introduced, named as TLS_FALLBACK_SCSV. This is not a cipher suite containing crypto algorithms, and a server cannot select it during the handshake. This merely indicates that that the connection is a fallback, and server should throw a fatal exception if it detects that the highest protocol version supported by the client is higher than the highest supported version of the server. This is specifically needed if the server supports lower TLS/SSL versions. In Qualys SSL Labs TLS test, this is one of the indicators of the security state of the server, and is shown as:

Some Common Attacks on TLS

Though TLS provides a very robust way of secure communication, they are not “silver bullets”, and over the period, the attackers have come up with multiple ways to break the TLS security. Most of these vulnerabilities arise due to implementation flaws, incomplete or vague specifications etc. Most of these are mitigated with TLS 1.3, by disabling weaker cipher suites, features (e.g. compression, re-negotiations, and downgrading).

Here are some of the very common attacks on TLS:

1. ROBOT (CVE-2017-6168): This is a recreation of the Bleichenbacher’s Oracle Threat, which essentially exploits the padding (as defined in PKCS# 1.5) of the TLS server error messages, by performing a chosen plaintext attack.
2. ROCA (CVE-2017-15361): This is an attack, which allowed the attacker to retrieve the private key from the public key generated by services, without even having physical access to the device. This was a flaw in the TLS library from German semiconductor firm, Infineon Tech.
3. Sweet32 (CVE-2016-2183): This attack breaks all 64-bit block ciphers with CBC mode in TLS by using the birthday attack, which would lead the attacker to perform a MiTM attack or inject malicious JavaScript code.
4. FREAK (CVE-2015-0204): The FREAK (Factoring on RSA-Export keys) is achieved by tricking the server into negotiating over a previous version of TLS (e.g. SSL 3.0 or TLS 1.0) and forcing it to use cryptographically weak cipher suites (aka. export grade RSA keys, which essentially are keys with 512-bit or less).
5. DROWN (CVE-2015-3197):  DROWN (Decrypting RSA with Obsolete and Weakened encryption) is an attack on the configuration of a server supporting a combination of protocols, containing the SSL v2 protocol. The researchers estimated that 33% of all HTTPS sites were affected by this vulnerability as of March 1, 2016.
6. LOGJAM (CVE-2015-4000): The LOGJAM attack is a vulnerability against the Diffie-Hellman key exchange with sizes between 512-bit to 1024-bit keys. It exploits the method of pre-compute steps for number field sieve algorithm to factorize a 512-bit prime, and then use the steps to factorize keys of up to 1024-bits.
7. SLOTH (CVE-2015-7575):  This attack targets TLS 1.2 which uses RSA-MD5 signature.
8. Heart Bleed (CVE-2014-0160): The Heartbleed bug is a serious vulnerability specific to the implementation of SSL/TLS in the popular OpenSSL cryptographic software library. This weakness, allows attackers to steal private keys from servers, by exploiting a buffer overflow on the server memory storing the private key.
9. 3SHAKE (CVE-2014-1295): If a TLS client connects to a malicious server and presents a client credential, the server can then impersonate the client at any other server that accepts the same credential. Concretely, the malicious server performs a man-in-the-middle attack on three successive handshakes between the honest client and server and succeeds in impersonating the client on the third handshake. This can be mounted to perform a man-in-the-middle attack.
10. POODLE (CVE-2014-3566): The POODLE (Padding Oracle on Downgraded Legacy Encryption) is a vulnerability in SSL 3.0, and if the server supports SSL 3.0, the attacker can downgrade the protocol to exploit this vulnerability. It was re-purposed to work with TLS 1.x, as reported by F5 networks in a separate CVE (CVE-2014-8730). The main target is browsers because the attacker must inject malicious JavaScript to initiate the attack. A successful attack will use about 256 requests to uncover one cookie character or only 4096 requests for a 16-character cookie.
11. Lucky13 (CVE-2013-0169) – It is a timing attack against the MAC operation in the TLS protocol using CBC mode operation.
12. CRIME (CVE-2012-4929)and BREACH (CVE-2013-3587): Both the CRIME and BREACH was found by the same author, where an encrypted cookie content can be retrieved if compression is enabled with TLS.
13. BEAST (CVE-2011-3389): The BEAST is a TLS 1.0 implementation flaw, where the symmetric encryption that happens after the key exchange, used a weak IV of the AES-CBC, which was predictable. Thus, the encrypted traffic or part of it can be broken.
14. SMACK-SKIP (CVE-2015-2318): This attack is like FREAK, against browsers which used faulty implementation of weak export cipher suites.
15. RC4 attacks (CVE-2013-2466): If RC4 stream cipher algorithm is used as an encryption mechanism for the TLS connection, it cannot be trusted, as RC4 has numerous vulnerabilities, as reported over the period. As result is not recommended to use any of the RC4 cipher suites in your TLS connection. TLS 1.3 removes RC4 from all its supported cipher suites.
16. SSL Strip: SSL Strip attack is a form of downgrade attack, which is done when an attacker downgrades the elevation of the protocol. For example, a website is on HTTP, and the attacker has access to the traffic. The website at some point would upgrade to connect to HTTPS (say in the login screen). The attacker would intercept that upgrade request, and force the traffic to stay at HTTP, which essentially can all be intercepted and viewed by the attacker. A point to note, for this to be successful the website must at some point communicate with the server over HTTP. This is called a “mixed mode“, and most browsers these days would show a warning about this. So, it is always recommended to have your website be fully HTTPS, if ever at any point you want to upgrade to HTTPS. Another common mitigation that can be implemented by the server is to enforce HTTPS connections. The server can tell the client that it will only accept HTTPS traffic, in which case the client is always forced to use HTTPS, and an attacker using an HTTP connection would be denied by the server. This is called HTTP Strict Transport Security (HSTS) and can be specified as an HTTP header.

It is imperative to mention that this list is not exhaustive, and there are numerous attacks mitigated by different versions of the TLS protocol.

Conclusion

As mentioned above the TLS connection initialization starts from the client side, by providing the supported TLS version and the cipher suites, and the server selects from the list. So, the support for new version of TLS and cipher suites starts from the client first. The clients would use in most cases, the web browsers to access these servers. But not all web browsers support the newer version at the same time, or even if they do, not all clients update to the newer versions of the browsers. To handle this, the server would always have to support multiple versions of TLS and multiple sets of cipher suites (sometimes weaker). A quick view in Qualys SSL Labs TLS test for the http://www.google.com website tells us (at the time of writing this article) the TLS versions it supports:

Supported TLS versions (default in green):

Supported cipher suites:

Due to this, it is extremely important to ensure that the right cipher suites and version are enabled. Support for broken and weaker version and algorithms should be disabled. TLS 1.3 helps this significantly by ensuring that weaker cipher suites and features cannot be used with it. So, we should strive to have our minimum supported version as TLS 1.2 and default to TLS 1.3.