TLS 1.2 vs. 1.3—Handshake, Performance, and Other Improvements

Communication security and privacy remain a major concern in today’s digitally interconnected world. The first protocol to provide secure and encrypted connections over the Internet was the Secure Socket Layer (SSL), which used public key cryptography. In 1999, SSL was upgraded to version 3 and standardized as Transport Layer Security version(TLS) 1.0. These protocols are now replaced with more secure TLS 1.2 and 1.3 versions. 

Transport Layer Security is the standard that ensures that all communication over the public Internet remains secure and tamper-proof. It provides confidentiality, authentication, integrity, and protection against replay attacks. 

This article explores TLS 1.2 vs. 1.3 changes and improvements in TLS 1.3.

TLS 1.2 vs. 1.3—summary of differences 

The TLS 1.2 was released in 2008 and documented in RFC 5246. The upgrade included several enhancements that replaced weaker cipher suites with stronger ciphers. TLS 1.3 was released ten years after version 1.2 in 2018. IETF standardized the latest release in RFC 8446. The significant changes in 1.3 from 1.2 include the following:

Handshake process

Both protocols start with a handshake process that creates a secure/encrypted tunnel between a client and server using a combination of asymmetric and symmetric encryption. The actual data transfer takes place after the handshake is completed. 

The TLS 1.2 handshake process was prolonged and time-consuming. TLS 1.3 has made it more efficient and enhanced security. 

TLS 1.2

The TLS 1.2 handshake requires two round trips (2-RTT) or message exchanges between client and server to complete. The process is as follows.

Client hello

The client initiates a TLS handshake with a Client Hello message that includes:

1. Client-supported TLS versions
2. Client-supported cipher suites
3. A random number that will be used to generate an encryption key at a later step.
4. A non-empty session ID if the client wants to resume a previous session with the server.

Server hello

If the Client Hello had a non-empty session ID, the server searches for a previous cached session and resumes it. If empty, the server generates a new random Session ID. It then responds with a Server Hello message that includes:

1. TLS version chosen from the list included in the client Hello.
2. Cipher suites selected from the list included in the client Hello. 
3. A server-generated random number for the encryption key in the later step.
4. The Session ID
5. A signed SSL/TLS certificate which includes the public key of the server.

The server then sends a Server Hello Done message to the client

Key exchange

After receiving Server Hello Done, the client validates if a Certificate Authority trusts the server certificate. After validation, it sends a Key Exchange message with a randomly generated pre-master key to the server encrypted with the server’s public key. 

The server decrypts the pre-master key using its private key. The client and server generate a master secret using the previously shared random numbers and the pre-master key. Both use the shared master secret to generate session keys.

Handshake finished

Finally, the client sends a Change Cipher Spec message to the server, stating that it is switching to symmetric encryption using session keys, followed by the Handshake Finished message.

The server also responds with a Change Cipher Spec message and a Handshake Finished message, indicating that it is also ready to use the shared symmetric key. 

The client and server now start exchanging fully encrypted data using the session keys. These keys are temporary and only last for the duration of the session between the client and the server.

TLS 1.3

In comparison, the TLS 1.3 handshake process is completed in one round trip (1-RTT).

Client hello

The client initiates a TLS handshake with a Client Hello message that includes:

• Offered protocol version (1.3)
• Client-supported cipher suites
• Client-supported key-exchange methods
• Client-generated random number
• Any optional extensions

Server hello

The server generates the master secret using the ClientHello random number, its own generated random number, client parameters, and cipher suites. It then responds with a Server Hello and Server Finished message that includes:

• Server selected protocol version (1.3)
• The server selected cipher suites
• The server selected key exchange method
• Server-generated random number 
• Server SSL/TLS certificate 
• Any optional parameters

Handshake finished

The client verifies the Server certificate, generates the master secret, and sends the Client Finished message. The client and the server then immediately start exchanging data over symmetric encryption.

TLS 1.2 vs 1.3—feature differences

Some features from TLS 1.2 have not been continued in 1.3. Several new features have also been added.

Algorithms

The legacy and weak encryption algorithms from TLS 1.2 have been removed. TLS 1.3 now only supports Authenticated Encryption with Associated Data (AEAD) algorithms. AEAD is a type of encryption that simultaneously provides data confidentiality, integrity, and authenticity assurances. It combines and processes the data being encrypted (the plaintext) and additional data that needs integrity but not confidentiality (the associated data). This integrated approach ensures that the encrypted data (ciphertext) cannot be tampered with or forged without detection, and any modifications are immediately noticeable upon decryption.

Version control

In TLS 1.2 and earlier versions, the version negotiation mechanism allowed clients and servers to communicate the highest version of TLS that both could support. However, this process was susceptible to manipulation by attackers who could intercept the negotiation process and modify the messages to force using an older protocol version. TLS 1.3 simplifies this process by requiring that clients and servers support TLS 1.3 if it is to be used.

Compression

TLS versions before 1.3 supported compression and a list of supported compression methods were exchanged in Client Hello. However, these methods have been exploited in some attacks. TLS 1.3 now sends a null byte(in legacy_compression_methods), effectively removing compression from the protocol. 

Digital signature verification

When a server presents its certificate to the other party as part of the TLS handshake, it also provides a digital signature to prove that it is the rightful owner of the certificate. Digital signatures are also used to validate the key exchange process. 

TLS 1.2 supports a variety of cipher suites(primarily RSA) for signature verification, and the choice depends on what both the client and server support and prefer. 

In contrast, TLS 1.3 emphasizes the use of the Elliptic Curve Digital Signature Algorithm(ECDSA), which uses smaller key sizes, resulting in faster computations, less bandwidth usage, and quicker connections. TLS 1.3 limits RSA usage to more secure padding schemes (specifically, RSASSA-PSS) and generally encourages the use of elliptic curve cryptography.

Forward secrecy

Forward secrecy refers to ephemeral key exchange mechanisms that generate a new, unique session key for each secure communication session. 

TLS 1.3 mandates the use of forward secrecy. As discussed in the previous section, during the TLS 1.3 handshake process, the client and the server both independently compute a unique session key using the Ephemeral Diffie-Hellman key exchange protocol. The keys are mathematically computed using the client and server random numbers and the selected cipher suites. These session keys do not travel over the network and are discarded after each session is over. 

The goal is to protect the privacy of past sessions so that even if an attacker captures the server’s private key, they cannot decrypt the entire data exchange. 

TLS 1.2 vs 1.3 performance

TLS 1.3 greatly improves upon the performance of version 1.2. 

Reduced handshake latency

The TLS 1.2 requires two round trips to complete the handshake process. TLS 1.3 combines the initial handshake and the negotiation of cryptographic parameters into one round trip. This effectively reduces the handshake time by half. 

TLS 1.3 also offers a 0-RTT handshake, in which the client and the server can resume a previously established TLS session. To initiate data exchange with zero round trip, both the client and the server need to retain the session keys. They exchange data before the server properly verifies the client’s identity. 

Suppose an attacker has previously intercepted the client-server communication. In that case, the attacker can replay the client data to the server, and the server will not be able to verify whether it is legitimate or not. Hence, the 0-RTT handshake is not recommended.

Reduced computational overhead

TLS 1.3 removes the outdated cipher suites and cryptographic functions from the negotiation process. It also simplifies the key exchange process by using the Diffie-Hellman key exchange and removing the need for separate key exchange mechanisms like RSA used in TLS 1.2. Both these improvements simplify the computational overhead on both the client and the server.

TLS 1.3 adoption

If you haven’t done so already, it is best to upgrade to TLS 1.3.

Various regulatory and standards organizations are incorporating TLS 1.3 into their compliance requirements to ensure secure transmission across different networks.

For example, the National Institute of Standards and Technology (NIST) Special Publication 800-52 Revision 2 provides guidelines for implementing TLS 1.3 in federal systems. NIST requires organizations to plan and add support for TLS 1.3 by January 2024. This mandate underscores the importance of upgrading to TLS 1.3 to align with industry standards and best practices.

Other common standards, like the Payment Card Industry Standard Security Council (PCI-DSS) and the Health Insurance Portability and Accountability Act (HIPAA), also refer to NIST SP 800-52 guidelines.A large number of websites are using both 1.2 and 1.3 to maintain interoperability with most end devices. Qualys SSL Labs performs continuous surveys of the top 150,000 most popular sites (as per Alexa). As per the scan of February 2024, 99.9% of sites support version 1.2, with 67.8% of sites now supporting TLS 1.3.

The primary challenge with TLS 1.3 adoption is limited client device support. The following browsers and applications fully support TLS 1.3 as of this writing.

• Firefox 63+
• Chrome 70+
• Edge 75+
• Opera 57+
• Safari 12.1+
• Android 10.0+
• Java 11+
• OpenSSL 1.1.1+

Configuration options

Mozilla provides an SSL configuration generator to enable TLS 1.3 in many server softwares. The following is the recommended configuration of the Apache 2.4.41 web server with TLS 1.3 only enabled.

<VirtualHost *:80>
    RewriteEngine On
    RewriteCond %{REQUEST_URI} !^/\.well\-known/acme\-challenge/
    RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
</VirtualHost>

<VirtualHost *:443>
    SSLEngine on
    SSLCertificateFile      /path/to/signed_cert_and_inter_certs
    SSLCertificateKeyFile   /path/to/private_key
    Protocols h2 http/1.1
    Header always set Strict-Transport-Security "max-age=63072000"
</VirtualHost>

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2
SSLHonorCipherOrder     off
SSLSessionTickets       off

SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

Last thoughts

TLS is vital in securing transmission over any network infrastructure using public key encryption and a handshake mechanism between clients and servers. Compared to TLS 1.2, TLS 1.3 offers improved security, enhanced performance, and streamlined functionality. If you are struggling with performance issues, upgrading your TLS is just the first step. You also need end-to-end visibility into your environment to identify bottlenecks and reduce MTTR. With the right monitoring and observability tools, you can gain insight into performance across user connectivity, public and private networks, data centers, and application layers so you can more quickly diagnose and resolve issues.

FAQs