TLS Versions Explained Difference between TLS 1.2 vs TLS 1.3
Transport Layer Security (TLS) is a cryptographic protocol that provides secure communications over a network. It encrypts and authenticates communication between applications and servers, ensuring privacy and data integrity.
TLS evolved from the Secure Sockets Layer (SSL) protocol and is also sometimes still referred to as SSL. However, SSL was deprecated with the release of TLS 1.2 in 2008. Since then, TLS has gone through several versions with improvements in encryption strength, performance, and security.
The two most common versions still in use today are TLS 1.2, introduced in 2008, and the latest TLS 1.3 protocol, finalized in 2018. These versions contain significant differences that affect things like handshake time, cipher suites, encryption algorithms, and more.
This article will provide an overview of the evolution of TLS and make a comparison between TLS 1.2 vs TLS 1.3, highlighting the key differences and improvements in the latest version.
Key Takeaways
- TLS evolved from SSL and provided encrypted communication between clients and servers.
- TLS 1.2 introduced in 2008 is still commonly used while TLS 1.3 came out in 2018.
- TLS 1.3 has improved encryption strength with mandatory forward secrecy and AEAD ciphers.
- The TLS 1.3 handshake is faster and more efficient than previous versions.
- TLS 1.3 removes old weak cipher suites and cryptographic algorithms.
- Improvements in TLS 1.3 enhance user privacy, security, and performance.
Head-to-Head Comparison Between TLS 1.2 vs TLS 1.3
| Feature | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Handshake | Uses multiple roundtrips | Uses a single roundtrip (1-RTT or 0-RTT for resumption) |
| Key Exchange | Supports a variety of key exchange methods | Uses only Elliptic Curve Diffie-Hellman (ECDHE) |
| Cipher Suites | Supports a wide range of cipher suites | Supports only AEAD ciphers (e.g., AES-GCM, ChaCha20-Poly1305) |
| Encryption Algorithm | Supports a variety of encryption algorithms | Uses only AEAD ciphers (e.g., AES-GCM, ChaCha20-Poly1305) |
| Perfect Forward Secrecy | Supports PFS with specific ciphers | Perfect Forward Secrecy (PFS) is mandatory |
| Resumption | Session IDs or Session Tickets | Pre-Shared Keys (PSK) or Resumption PSK |
| Compression | Supports compression | Compression is disabled |
| Renegotiation | Supports renegotiation | Renegotiation is prohibited |
| Version Negotiation | Supports version negotiation | Version negotiation is not used |
| Downgrade Protection | Limited protection against downgrade attacks | Improved protection against downgrade attacks |
| Crypto Agility | Limited crypto agility | Improved crypto agility |
| Privacy | Limited privacy protections | Improved privacy protections (e.g., Encrypted Server Name Indication) |
The Evolution of TLS
TLS is a standardized protocol defined by the Internet Engineering Task Force (IETF). It goes through lengthy standards process with different draft versions before being finalized.
Here’s a quick look at how TLS has evolved over time:
- SSL 1.0: First introduced in 1994 by Netscape but had many flaws. Never publicly released.
- SSL 2.0: Released in 1995 to fix problems with SSL 1.0. Also plagued with security issues and quickly deprecated.
- SSL 3.0: Released in 1996 with improved security and encryption. Became the standard for many years.
- TLS 1.0: Released in 1999 to update SSL 3.0 with a new name. Very similar to SSL 3.0.
- TLS 1.1: Released in 2006 based on TLS 1.0. Small improvements like protection against CBC attacks.
- TLS 1.2: Released in 2008 with major changes like new cipher suites. The most commonly used TLS version today.
- TLS 1.3: Released in 2018 with improved security and performance. The newest TLS version.
TLS 1.2 has been around for over 10 years now and is supported on most modern systems and web servers. However, TLS 1.3 adoption has steadily grown since its release in 2018.
As of 2022, TLS 1.3 accounts for approximately 30% of HTTPS traffic on the web. All major web browsers now support it. Many large companies like Google, Facebook, and Cloudflare have also adopted TLS 1.3.
Some key motivations pushed for the development of TLS 1.3:
- Stronger encryption: TLS 1.2 encryption had some vulnerabilities. TLS 1.3 improves algorithms and key lengths.
- Faster connections: TLS handshakes have become slower over time as encryption strengthened. TLS 1.3 improves handshake efficiency.
- Improved privacy: TLS 1.2 could expose some user data during the SSL/TLS handshake. TLS 1.3 reduces this surface attack area.
- Stronger authentication: Technologies like certificate pinning and token binding improve authentication in TLS 1.3.
Now let’s look at some of the specific differences between these two popular versions of TLS.
Key Differences Between TLS 1.2 and TLS 1.3
There are several important differences between TLS 1.2 vs TLS 1.3 that improve security, performance, and privacy:
Removal of Weak Cipher Suites
TLS 1.3 removes all cipher suites using outdated algorithms deemed weak or insecure. This includes cipher suites using:
- MD5 and SHA-1 hashing algorithms
- RC4 stream cipher
- DES and 3DES symmetric encryption
These outdated algorithms are vulnerable to cryptographic attacks with modern computing.
TLS 1.3 only supports AEAD cipher suites using strong algorithms like AES-GCM and ChaCha20. The allowed cryptographic pairs are:
- TLS_AES_128_GCM_SHA256
- TLS_AES_256_GCM_SHA384
- TLS_CHACHA20_POLY1305_SHA256
Mandatory Forward Secrecy
TLS 1.2 supported optional forward secrecy for key exchanges using Diffie–Hellman and elliptic curve Diffie–Hellman.
TLS 1.3 now mandates forward secrecy for all sessions. This means new unique symmetric keys are generated for every session. Even if long-term private keys get compromised, an attacker cannot decrypt previous communications.
TLS 1.3 only uses ephemeral Diffie-Hellman and elliptic-curve Diffie-Hellman key exchanges which provide forward secrecy by default.
Faster Handshake Time
The TLS handshake sets up the encrypted session and authenticates the server. TLS 1.2 and below required two round trips to complete a full handshake.
TLS 1.3 reduces this to one round trip or zero round trips with session resumption. This means the handshake completes faster.
Some of the optimizations in the TLS 1.3 handshake include:
- Removing static RSA key exchanges
- Making key shares extensible to allow future algorithms
- Adding PSK-based resumption capability
Benchmarks show TLS 1.3 handshake completing in approximately half the time compared to TLS 1.2.
Reduced Handshake Transcript Size
In TLS 1.2, client and server would exchange large amounts of data during the handshake process. This included things like random values, certificates, key shares, and more.
TLS 1.3 reduces the total size of data transferred during the handshake, especially during resumption handshakes which transfer almost no data.
The overall handshake transcript is much smaller in TLS 1.3 compared to TLS 1.2. This improves performance.
Improved Client Authentication
TLS 1.3 improves support for authenticating clients with certificates during mutual TLS authentication.
It adds new CertificateVerify and Finished messages to explicitly validate the client certificate. The CertificateVerify signature also covers the entire handshake improving security.
TLS 1.3 also supports other client authentication methods like PSK and external PAM authentication.
Enhanced Privacy
TLS 1.3 makes several changes to improve user privacy:
- Removing static RSA cipher suites prevents attackers from passively detecting the client and server certificates.
- Encrypted Server Name Indication (ESNI) hides the hostname in the TLS ClientHello.
- The reduced handshake size discloses less information.
- Removal of Compression in TLS 1.3 eliminates compression oracles like CRIME attacks.
- New session hash algorithms use only the server’s handshake data rather than material derived from both client and server handshakes.
Improved Resumption and PSK Support
Session resumption allows clients and servers to reuse cryptographic parameters from a previous connection to establish a new connection quickly.
This avoids the computational costs of exchanging keys and keeps handshake latency low. TLS 1.3 improves resumption capabilities by:
- Adding PSK-based resumption along with session ticket-based resumption.
- Using PSK-based resumption as the primary resumption method.
- Adding support for both external PSK and those negotiated on the original connection.
- Removing nonces from tickets to avoid ticket replay attacks.
These changes make session resumption more efficient and secure in TLS 1.3 compared to older versions.
Removal of Static RSA Key Exchange
Previous versions of TLS supported static RSA key exchanges where servers would use certificates with RSA keys to encrypt session keys and exchange them with clients.
The RSA key exchange is removed in TLS 1.3 since it does not provide forward secrecy. Only ephemeral Diffie-Hellman exchanges are allowed which provide forward secrecy by default.
This improves security and reduces handshake latency by avoiding RSA operations which can be computationally expensive.
Mandatory Peer Authentication
TLS 1.2 allowed anonymous key exchanges where peers did not authenticate each other during the handshake.
TLS 1.3 requires endpoints to authenticate each other during every handshake based on the key exchange algorithm in use. This protects against man-in-the-middle attacks.
Record Layer Changes
TLS 1.3 modifies the TLS record layer used to transmit application data:
- The MAC-then-Encrypt order is reversed to the more secure Encrypt-then-MAC.
- Padding is removed since all ciphers are AEAD algorithms that provide their own padding.
- Connection IDs are added to allow multiplexing of connections.
TLS 1.3 Backward Compatibility
TLS 1.3 is designed to be backward compatible with TLS 1.2 and older versions of TLS/SSL. This allows clients and servers with mixed support for protocols to negotiate the highest common version supported by both parties.
For example, if a client only supports TLS 1.2 it can still connect to a server that supports TLS 1.3. The connection will simply be TLS 1.2 rather than the newer 1.3 version.
To ensure backward compatibility, TLS 1.3 follows the same basic TLS 1.2 message flow:
- ClientHello: Client sends supported TLS version in ClientHello
- ServerHello: Server responds with highest supported version
- Authentication: Certificates exchanged
- Key Exchange: Generate shared keys
- ChangeCipherSpec: Apply negotiated parameters
- Finished: Final confirmation message
- Application Data: Encrypted user data transmitted
This backward compatible design allowed for a smoother transition process to TLS 1.3.
When Should You Use TLS 1.3?
Here are some general guidelines on when to use TLS 1.3:
- For new applications and services: TLS 1.3 should be the default for any new deployment using TLS today. It’s more efficient, secure, and supported on modern systems.
- After upgrading backend servers and load balancers: TLS 1.3 requires server-side support. So existing infrastructure needs to be updated first.
- For public-facing services and websites: TLS 1.3 improves security and user experience for public services that handle sensitive user data or transactions.
- For services accessed by modern web and mobile apps: Apps on current devices and browsers will benefit from faster TLS 1.3 connections.
- When forward secrecy is important: Mandatory forward secrecy in TLS 1.3 can provide additional protection for encrypted data, especially sensitive communications.
- After testing compatibility: Endpoints still using older systems should be tested for compatibility with TLS 1.3 before deploying it.
TLS 1.3 is designed to smoothly replace 1.2 over time with improved security and performance. But both versions will co-exist during the transition period as TLS 1.3 adoption grows.
Step-by-Step Guide for Migrating from TLS 1.2 to 1.3
Here are some steps for migrating from TLS 1.2 to 1.3:
- Update server software: Upgrade web and application servers to a version that supports TLS 1.3. Enable TLS 1.3 alongside 1.2.
- Update load balancers: If using hardware or software load balancers, update their firmware/software to TLS 1.3 capable versions.
- Test endpoints: Verify client devices and web browsers accessing your servers work properly with TLS 1.3 connections. Check for any compatibility issues.
- Enable TLS 1.3 on frontends: Gradually roll out TLS 1.3 support on public-facing servers like web servers, mail servers, etc. handling external TLS traffic.
- Transition Backoffice services: Finally, transition internal backend servers, APIs, databases, and other systems to use TLS 1.3.
- Monitor TLS usage: Use analytics to monitor adoption of TLS 1.3 versus 1.2 connections after migrating.
- Disable legacy protocols: Once TLS 1.3 usage is sufficiently high, disable outdated protocols like TLS 1.0/1.1 and SSL 3.0.
The process involves gradually enabling TLS 1.3 support across infrastructure and services, testing everything thoroughly, before eventually disabling older versions of SSL/TLS.
Conclusion on TLS 1.2 and 1.3
In conclusion, TLS 1.3 offers significant security and performance improvements over previous TLS versions. With faster connection establishment, reduced latency, and improved encryption algorithms, TLS 1.3 enables faster and more secure communication for modern web applications. However, TLS 1.2 is still widely used today across the internet. The transition to TLS 1.3 will take time as organizations update their servers and clients. During this transition, understanding the differences between TLS 1.2 and 1.3 will be key for administrators to maintain compatibility while reaping the benefits of the latest TLS version. Careful testing and gradual deployment of TLS 1.3 will lead to a more secure web in the future.
FAQs About TLS 1.2 vs TLS 1.3
Is TLS 1.3 a major update over 1.2?
Yes, TLS 1.3 represents a major update to TLS protocols with improvements in encryption strength, performance, and privacy. It’s not just an incremental change.
Does TLS 1.3 replace 1.2?
TLS 1.3 is designed to replace TLS 1.2 over time as systems are upgraded. However, TLS 1.2 will co-exist with 1.3 during the transition period to ensure backward compatibility for older systems.
What are the risks of using TLS 1.2 now?
TLS 1.2 is still considered secure when configured properly using strong cipher suites and keys. However, TLS 1.3 is more resilient to new attacks discovered in TLS protocols and cryptographic primitives.
Can TLS 1.3 work with older browsers/devices?
Yes, TLS 1.3 implements fallback logic to use TLS 1.2 or older versions when connecting to clients that don’t support it. However, some features will not be available.
How do I check if a site uses TLS 1.3?
Browser developer tools or services like SSLLabs can scan and test sites to determine if TLS 1.3 is supported and enabled. Client Hello messages can also be inspected.
Is ESNI supported in TLS 1.2?
No, ESNI or Encrypted Server Name Indication is only available in TLS 1.3. This hides the destination hostname in the initial TLS handshake.
