A dive into TLS 1.3 Architecture and its advantages over TLS 1.2

Over the past few days, I had been messing around with TLS 1.3 for a work project. HTTPS is something we use in our daily lives and it protects our data so this was an interesting topic as it was more about researching and learning something new. I went through quite some articles so just want to share what I have learned with anyone exploring this domain.

Let’s start with the basic stuff first.

What is HTTPS?

HTTP stands for Hyper-Text-Transfer-Protocol which basically standardizes the way data is to be transferred over the internet. The ‘S’ stands for ‘Secure’. HTTP alone transfers data in plaintext form. There is almost no encryption and security. That means anyone who is sniffing those small data packets you are sending over the wire can see exactly what data you send including passwords, payment details, etc. HTTPS makes sure any data you are sending over a network is encrypted. This data can only be read by the two parties in the connection — The client (You) and the Server (The service you are exchanging data with). Even if someone in the middle gets a hold of this encrypted data they won’t be able to read it since the keys to decrypt this data are present only with the parties involved. This is how data is protected.

What is TLS and how is HTTPS related to TLS?

You might have heard about SSL before. It’s the Secure Sockets Layer which was the definition of how HTTPS was going to be achieved. TLS or Transport Layer Security is an upgraded version of SSL. TLS is the protocol that defines how authentication is to be achieved between the Client and Server and how the data is supposed to be transferred between them. The history of SSL/TLS is out of the scope of this post but you can read more about it here.

TLS 1.2 and TLS 1.3

TLS 1.2 held the reigns for HTTPS for about 10 years. It is still used by most websites. The main reason is that TLS 1.3 is drastically different than TLS 1.2 in terms of architecture and security. So not all companies have adopted it yet but it is definitely recommended to use TLS 1.3 as it is faster and more secure than TLS 1.2. TLS 1.2 architecture is not the aim of this article but we will discuss the differences between TLS 1.2 and TLS 1.3 at the end.

Terminologies

Before we dive into the architecture, there are some technical terms you should understand since they will be used multiple times:

• Certificate — This is a mathematically generated long sequence of numbers that are signed by an organization. This certificate is issued to verify the identity of a website.
• Certificate Authority (CA) — This is the organization that signs the certificate. It can be a globally recognized organization or a private organization depending on the network type. Browsers usually trust only globally recognized ones.
• Cipher — It is an algorithm that mathematically encrypts some data. These can be symmetrically encrypted or asymmetrically encrypted.
• Cipher Suite — It is a set of ciphers to be used for the encryption of data over TLS.
• RTT — Round trip time, one signal from client to server and back to the client is 1 RTT.

TLS 1.3 Architecture

For this architecture, we will take 2 entities — The client and the server. The client can be a web browser and the server will be any web server with which the client wants to communicate.

TLS protocol aims to achieve three things:

• Authentication — The client should know if the server is actually who it says it is. Basically, there should not be a middleman between the server and the client. In some cases, the server also requires the client should verify itself so that both parties know who they are talking to.
• Confidentiality — The data that the client and server exchange should be encrypted and only they should be able to decrypt it so that even if someone intercepts the communication, they would not be able to read the data.
• Integrity — The data in transit should not be tampered with. This means that if some other source changes the data, the server or client should understand that something is wrong with the data and they should reject that data.

Authentication

The authentication is achieved in something called the TLS handshake. In this the client and server exchange some data to verify each other and to tell each other that they would like to communicate.

In the handshake, the client and server exchange a shared key. This shared key is what they use to encrypt the data that they communicate between them. This key exchange happens through a process called the Diffi Hellmann Ephemeral (DHE) key exchange. It requires the client and server to generate new keys for each new session and securely uses these keys to generate a shared key on each side without ever transferring the private or public keys to each other.

Steps in Handshake:

• The client sends a hello to the server. This hello includes a random message, the client’s key share for DHE, and a list of cipher suites supported. The server is supposed to pick one cipher suite. The client also guesses the server’s preference for the cipher suite to be used. The benefit of this is that there is no extra round trip required for establishing the cipher suite and the key exchange can finish in the 1 RTT.
  However, if the server doesn’t support the client’s guessed cipher suite, it will attempt a hello retry where the client will need to again send a hello message with the server’s preferred cipher suite. But the number of cipher suites is so limited that there is very less chance of a hello retry.
• The server receives the client's hello and generates its own random number and key share. Since the server has the client’s key share, it can generate the shared key. The server then sends the server hello with the random number and its key share with the client. It also sends the certificate and the handshake digest along with the finished message. The handshake digest is a hash of the entire handshake data encrypted with the shared key. This is done to maintain the integrity of the handshake and prevent any replay attack. The certificate, digest, and finished message are encrypted with the shared key generated on the server side. The server also sends a request for a client certificate if it requires one. This will be done in those servers where the client has to verify itself as well. However, the public-facing internet generally does not need to verify clients.
• The client receives the server hello and the server’s key share. It uses that and its own key share to generate the shared key on its end. This way both the client and server have the shared key using DHE without ever exchanging any private keys. With the shared key the client decrypts the certificate and verifies the server’s identity. The client then sends the finished message and application data to the server which are both encrypted with the shared secret key. The client can also send a client certificate if the server has asked for one. Thus, the data transfer begins after one RTT. This application data is the data that the browser needs to display to the user. This can be a webpage or some API data.
• The server decrypts the client certificate if it required one. It also decrypts the application data sent by the client. It then generates a session ticket for the client and sends the ticket + application data in encrypted form. This session ticket is used to resume a previous session which is discussed later.

1 RTT Handshake in TLS 1.3

Confidentiality and Integrity

Once the client and server both have the shared secret key, confidentiality and integrity are both ensured. Data is encrypted with the shared key which only the client and server have. This data only means garbage to anyone who doesn’t have the shared key. Thus, confidentiality is maintained.
At the end of every data transfer a MAC (Message Authentication Code) is calculated using an algorithm specified in the cipher suite (more about that in the next section). This is used to verify the integrity of the data so that no one can tamper with the data.
Another term you should know is Perfect Forward Secrecy (PFS). This means that even if a shared key of a session is compromised, it cannot be used to decrypt data from previous sessions or future sessions. This is because the key exchange mechanism is DHE which ensures new keys are generated every time.

Resumption of a previous session

Every time a client connects with a server, a session is established and a session ticket is issued. This session ticket is the shared secret key of that session, encrypted with a Session Ticket Encryption Key (STEK) stored with the server only. The server keeps a track of all session tickets in its own data store. A client might not want to establish a new session for each and every session as the entire handshake has to be performed. So there is a way by which connection can be established and data transfer can take place in 0RTT compared to 1 RTT for a new session.

Connection resumption is not secure and has caveats. Connection resumption is a call the developers make to increase speed, but it is not recommended by TLS 1.3.

To resume a connection with the server the client sends a hello message with the following things:

• Session Ticket or PSK — PSK (Pre-Shared Key) is a key that is manually stored with the client and server beforehand for resuming connections.
• Application Data (Encrypted with the previously shared key)
• Random number and client key share — These are sent as a fallback in case the session ticket has expired so that a new handshake can be started in the same RTT.

The server receives the client hello and sends a server hello with the following data:

• Application Data
• New Session Ticket encrypted with the STEK.
• Random number, Key share, and certificate in case the session ticket expires.

Connection resumption with 0RTT in TLS 1.3

Caveats in 0-RTT Connection Resumption:

• A bare PSK is not forward secure. This means that if the PSK is compromised, all previous communications using that key can be decrypted.
• Increased exposure to compromise: Since session resumption relies on the client and server both retaining the same secrets from a previous session if either side’s secrets are compromised, it could allow an attacker to hijack the session. This is particularly true if the same session ticket is used multiple times.
• 0-RTT data is not as secure as data exchanged during a full handshake, because it is sent before the server has had the opportunity to verify the client’s identity. This means that an attacker who has previously intercepted the client’s communication with the server could potentially replay the client’s 0-RTT data to the server, and the server would have no way of knowing if the data was legitimate or not. This is called a replay attack.

This is the entire high-level architecture of how TLS 1.3 works. In the next section, we will discuss the differences between TLS 1.3 from TLS 1.2.

I suggest you get an overview of how TLS 1.2 used to work. Refer to this article if you have no idea about it. This will help you understand how is TLS 1.3 beneficial.

What’s new in TLS 1.3?

TLS 1.3 is safer. It removed the support for unsafe ciphers and techniques which exposed vulnerabilities. Previously, TLS 1.2 supported a wide range of cipher suites which made developers responsible for carefully choosing a cipher that can negate attacks. But not every TLS 1.2 implementation was so secure. TLS 1.3 allows only the best ciphers which are tested and proven to negate attacks.

TLS 1.3 is faster. RTT (Round trip time) is the amount of time it takes for one request to go from client to server and back to the client. TLS 1.2 required 2 RTTs for a new connection and 1 RTT for the resumption of a previous session. TLS 1.3 is 2 times faster as it takes 1 RTT for a new connection to be completed and 0 RTT to resume a previous connection. That means the client can directly start sending data on the first request if a previous connection is resumed.

List of things not included in TLS 1.3 from TLS 1.2:

• Static RSA key exchange since it didn’t support PFS (Perfect Forward Secrecy). This makes ECDHE (Elliptic Curve Diffie Hellmann Ephemeral) the default key exchange mechanism.
• Removed weak hashing algorithms. SHA256/SHA384 and POLY1305 are the supported ones.
• Removed most of the EC (Elliptic Curves).
• Arbitrary compression. TLS 1.2 used deflating which removes duplicate strings. This was exploited in previous attacks.
• Removed Renegotiation. Renegotiation is the process of renegotiating the parameters of an existing TLS connection between a client and a server. It is a way to modify the parameters of an existing secure connection to accommodate changes in security requirements or to add new security features.
• Removed all Non-AEAD Ciphers. AEAD (Authenticated Encryption with Associated Data) ciphers are a type of encryption algorithm used in the TLS (Transport Layer Security) protocol. Before TLS 1.3, the MAC was computed and then data was encrypted. However, this had security downsides. AEAD ciphers do both of these things simultaneously. Some popular AEAD ciphers in use today include AES-GCM and ChaCha20-Poly1305. Some of the ciphers that were removed are AES-CBC, RC4, DES, and 3DES.

Optimizations and safety features added to TLS 1.3:

• Only ECDHE used for key exchange
• A limited number of EC groups (curves 25519 and 448)
• Only suites with AEAD Ciphers (AES-GCM, AES-CCM, and ChaCha20) are supported. A list of cipher suites supported in TLS 1.3 are:

a) TLS_AES_128_GCM_SHA256

b) TLS_AES_256_GCM_SHA384

c) TLS_CHACHA20_POLY1305_SHA256

d) TLS_AES_128_CCM_SHA256

e) TLS_AES_128_CCM_8_SHA256

• Explanation of different parts of cipher suites:
  — The key exchange algorithm to use, is ECDHE and cannot be changed.
  — The Authenticated Encryption algorithm provides confidentiality and integrity protection for the data being transmitted. For example, AES_128_GCM in TLS_AES_128_GCM_SHA256 refers to the use of 128-bit Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM).
  — Message Authentication Code (MAC): The MAC algorithm provides a mechanism for verifying the integrity of the transmitted data. For example, SHA256 in TLS_AES_128_GCM_SHA256 refers to the use of the Secure Hash Algorithm (SHA-256) for message authentication.
• In TLS 1.2 only the finished message at the end is encrypted. In TLS 1.3 everything after the initial hello is encrypted. This includes Content-Type, SNI (Server Name Indication), Certificates, and Extensions. Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) protocol that allows a client to specify the hostname of the server it is connecting to during the initial handshake process. This enables a single server to host multiple SSL/TLS-protected websites, each with its own certificate, on the same IP address.
• Split and simplified negotiation of cipher suites. In TLS 1.3 the algorithms for the cipher suites are individually agreed upon to form the final cipher suite.
• Full handshake signature: The server and client send the entire handshake data for verification which is encrypted.
• Server Capability assumptions: The client makes some assumptions about the server’s cipher and protocol capabilities. The best case is that it speeds up the TLS and the worst case is a hello retry. But since the number of cipher suites is so less, there is less chance of the worst case happening.
• Digital signature algorithms: EdDSA, ECDSA, RSA

Conclusion

TLS 1.3 definitely fills a lot of shortcomings of TLS 1.2 and should be adopted as soon as possible. For businesses using TLS 1.2 for a long time, it will be difficult since their network depends on it. But for a new implementation or a less complex architecture, you should definitely use TLS 1.3. All major web servers like NGINX and APache already support TLS 1.3.

Thank you for taking the time to read this! Any suggestions and feedback will be appreciated. You can contact me in case you need more clarifications!

Email: ritikagrawal1292000@gmail.com
LinkedIn: https://www.linkedin.com/in/ritik-agrawal-b14886191/