An Overview of TLS 1.3 Cryptographic Protocol
Transport Layer Security (TLS) is a cryptographic protocol that provides communication security over a computer network. It encrypts and authenticates communications between two parties, such as a web browser and a web server. TLS is the successor to Secure Sockets Layer (SSL). TLS 1.3 is the latest version of the TLS protocol, published in August 2018. It aims to improve security and performance compared to previous versions.
Some of the key improvements in TLS 1.3 include:
Faster Connection Establishment
In previous versions of TLS, establishing a secure connection involved multiple round trips between the client and server. This added latency before encrypted communication could begin.
TLS 1.3 reduces this to a single round trip handshake, improving performance. This is achieved by:
- Using asymmetric encryption only for authenticating the server. Bulk data encryption uses faster symmetric cryptography.
- Removing unnecessary round trips in the handshake.
- Allowing the client and server to send data encrypted with session keys immediately after the first handshake message.
According to Google, TLS 1.3 handshakes are completed in one round trip about 40% of the time. This results in faster page load times for websites.
Removed Older Protocols and Algorithms
Older TLS versions supported weak cryptographic algorithms and protocols for compatibility. These outdated mechanisms could be exploited and compromised security.
TLS 1.3 removes support for:
- Weak symmetric encryption algorithms like RC4. Only AEAD algorithms like AES-GCM are used.
- Smaller key sizes like 512-bit RSA. At least 2048-bit keys are recommended.
- Older protocols like SSL 2.0 and 3.0, and TLS versions 1.0 and 1.1.
This improves security by removing outdated technology.
Improved Forward Secrecy
Perfect forward secrecy (PFS) prevents past encrypted communications from being decrypted if current session keys are compromised.
Previous TLS versions only offered PFS through mechanisms like DHE and ECDHE key exchange. But many servers did not enable PFS since it had a performance cost.
TLS 1.3 enables PFS by default for all sessions. This significantly improves forward secrecy protections compared to earlier TLS usage.
Protection Against Replay Attacks
Replay attacks capture valid encrypted packets and resend them to the server later. Since the encryption and authentication are still valid, this can fool the server into improper behavior.
TLS 1.3 adds replay attack protection:
- Each side generates fresh session keys for every connection. Replayed session keys will be rejected.
- The TLS protocol sequence numbers are encrypted. An attacker cannot replay packets while adjusting sequence numbers.
Reduced Handshake Fragmentation
The initial TLS handshake contains important metadata that sets up the secure session. To improve performance over lossy networks, earlier TLS versions allow this handshake to be fragmented into multiple TCP packets.
Unfortunately, some middleboxes on the network path like firewalls and NAT devices improperly drop fragmented packets. This causes the handshake to fail.
TLS 1.3 handshakes use fewer, larger packets. This reduces fragmentation and improves compatibility across middleboxes, leading to fewer failed connections.
0-RTT Mode
After establishing a TLS connection once, 0-RTT mode allows a client to resume the session later without any round trips. The client can send encrypted application data immediately using cached session parameters.
This significantly accelerates subsequent connections to the same server. However, 0-RTT mode has some limitations:
- The server cannot authenticate the client during 0-RTT, so it is most applicable to situations with low fraud risk.
- Support for 0-RTT is optional – the server must enable it.
- The security guarantees are weaker since keys are reused. 0-RTT data is replayable.
Improved Error Messaging
Earlier TLS versions did not clearly distinguish between different failure modes like network errors, certificate issues, protocol problems, etc.
TLS 1.3 defines distinct alert codes for common failure reasons like certificate expired, protocol version mismatch, and bad certificate.
This allows clients to better diagnose and handle issues. Browsers can provide clearer error messages to users as well.
Backward Compatibility
For backwards compatibility, TLS 1.3 clients and servers can fall back to earlier protocol versions like TLS 1.2 if needed. This allows a gradual transition to the new version.
Some endpoints may only support older TLS versions due to legacy software dependencies. TLS 1.3 can still work with these endpoints.
Adoption of TLS 1.3
As of 2023, TLS 1.3 adoption is growing steadily:
- Major web browsers like Chrome, Firefox, Edge, and Safari support TLS 1.3.
- Popular web servers like Apache HTTP Server and Nginx support TLS 1.3.
- Cloud services like AWS, Azure, and GCP offer TLS 1.3 support.
- TLS 1.3 comprised about 30% of total TLS traffic on the web in 2022.
Many major websites have deployed TLS 1.3 including Facebook, Wikipedia, Twitter, Apple, and Bank of America. However, some sites still use older TLS versions to support outdated clients.
Here are some key factors driving adoption of TLS 1.3:
Browser Support
Once modern browsers implemented support for TLS 1.3, many websites migrated to enable the new protocol version and take advantage of performance improvements.
Chrome fully supported TLS 1.3 since early 2018. Firefox, Edge, and Safari added support in subsequent months.
Cloud Services
Popular cloud platforms like AWS, Azure, and Google Cloud launched TLS 1.3 support in 2018. This allows cloud-hosted websites and services to easily benefit from the new TLS version.
Web Server Support
Leading open-source web servers including Apache HTTP Server and Nginx added TLS 1.3 support in 2018. This enabled web hosts to upgrade millions of websites to the new TLS version.
Recommendations
Standards bodies and industry groups have strongly recommended adopting TLS 1.3 to improve security and performance:
- IETF marked TLS 1.0 and 1.1 as deprecated in March 2020.
- PCI DSS compliance guidelines require newer TLS versions beginning in 2024.
- Mozilla announced it will mark TLS 1.0 and 1.1 as insecure in Firefox during 2023.
These recommendations apply pressure for organizations to upgrade to more recent TLS versions.
Performance Benefits
The faster connection establishment and reduced latency of TLS 1.3 provide strong performance incentives to upgrade.
For organizations trying to optimize web performance, TLS 1.3 is an easy win that improves user experience.
Over the next few years, TLS 1.3 is expected to become the dominant TLS version on the web as older clients and software fade out.
How Does TLS 1.3 Work?
Now that we’ve seen the improvements in TLS 1.3, let’s look at how the protocol establishes a secure connection between a client and server:
1. Initiate Connection
The client sends a ClientHello message to the server indicating it wants to start TLS negotiation.
This includes:
- The maximum TLS version the client supports
- A list of cipher suites the client can use
- A nonce (random value) to prevent replay attacks
The server responds with a ServerHello message confirming the TLS version, cipher suite, nonce, and other session parameters.
2. Establish Shared Keys
The client and server exchange keys to derive symmetric session keys for encrypting data:
- The server’s public key is used to encrypt a premaster secret sent by client.
- Both parties generate the master secret from the premaster using a key derivation function.
- Application traffic encryption keys are derived from the master secret.
This step authenticates the server and sets up keys for the TLS session.
3. Verify Server Certificate
The server provides its certificate to the client for verification:
- The certificate must be issued by a trusted certificate authority.
- The name on the certificate must match the server’s domain.
- The certificate must be currently valid and not revoked.
This proves the server’s identity to the client.
4. Finish Handshake
The client and server exchange Finished messages which are encrypted using the derived session keys.
These finish messages verify that both parties hold the same session keys and the handshake was successful.
5. Exchange Application Data
Finally, the client and server can exchange encrypted application data protected by TLS. Examples:
- A browser sending HTTPS requests after connecting to a web server
- Email clients using TLS to connect to mail servers
- API clients connecting to cloud services APIs
This traffic uses symmetric encryption and session keys setup during the handshake.
TLS 1.3 Features and Improvements
Let’s explore some of the major improvements in TLS 1.3 compared to previous versions:
1. Faster Handshakes
TLS 1.3 completes the handshake in one or two round trips, whereas TLS 1.2 required at least four round trips:
This is achieved via several optimizations:
- 0-RTT data: After a successful first handshake, clients can resume connections with 0 round trips. Cached parameters are reused to send data immediately.
- Combined server authentication: Server authentication happens during ephemeral key exchange instead of requiring separate steps.
- Key derivation prework: The client “pre-generates” key derivation work during its first flight, avoiding an extra round trip.
These changes significantly reduce the latency to establish a secure connection.
2. Mandatory Forward Secrecy
TLS 1.3 makes forward secrecy mandatory by only allowing ephemeral Diffie-Hellman key exchange methods.
Static RSA and Diffie-Hellman key exchanges are removed since they do not provide forward secrecy.
Now, compromising a server’s private key in the future won’t allow decrypting past communications. This improves long-term security.
3. Improved Error Reporting
TLS 1.3 defines new alert codes that allow clients to better identify the error when a connection fails:
- handshake_failure
- protocol_version
- decrypt_error
- certificate_expired
And many other specific failures. This is more helpful than TLS 1.2’s generic “bad_record_mac” and handshake failure alerts.
Clients like browsers can use these alerts to provide understandable error messages to users as well.
4. Replay Attack Defenses
Several changes make TLS 1.3 more resistant to replay attacks:
- Unique per-connection keys prevent replayed keys from being accepted
- Encrypted sequence numbers prevent tampering with request order
- Fresh nonces during handshakes avoid reused parameters
These protections reduce the risk of data or requests being replayed maliciously.
5. Improved Crypto Agility
TLS 1.3 removes old cryptographic algorithms and protocols and mandates more modern ones:
- Symmetric ciphers limited to AEAD suites like AES-GCM/ChaCha20-Poly1305.
- Hash functions simplified to just SHA-256.
- Signatures require RSA-PSS rather than vulnerable PKCS#1 v1.5 padding.
These prunes old crypto that may become weak over time, improving longevity and security.
6. Streamlined Protocol
Many artifacts from older SSL protocols were cleaned up:
- Compression support removed
- Custom DHE groups removed – standard ones only
- Renegotiation redesigned to be more secure
- Point format negotiation removed
This simplifies the protocol, removes unused features and legacy cruft.
Implementing TLS 1.3 – Server Changes
For website and server operators, what’s required to implement TLS 1.3?
Let’s go over the changes needed on the server side:
1. Use a TLS 1.3 Compatible Web Server
Most major web servers like Nginx, Apache, and IIS now support TLS 1.3. Ensure you’re on a recent version that has full TLS 1.3 capabilities enabled.
2. Obtain a TLS 1.3 Compliant Certificate
Your server certificate must use modern cryptographic standards compatible with TLS 1.3:
- Minimum 2048-bit RSA key
- SHA-2 signature hash algorithm
- Must contain an OCSP Must-Staple extension
Old 1024-bit RSA certificates or SHA-1 signatures will not work.
3. Update Cipher Suite Configuration
You’ll need to allow strong cipher suites compatible with TLS 1.3 such as AES-128-GCM and ChaCha20-Poly1305.
Remove cipher suites with obsolete cryptography like SHA-1, RC4, or export-grade encryption.
4. Test Client Compatibility
Verify client software you need to support has TLS 1.3 available. This includes:
- Web browsers – Latest Chrome, Firefox, Safari
- API/SDK clients – Python, .NET Core 2.1+, Java 11+
- Mobile OSes – Android 10+, iOS 13+
- Email clients – Outlook 2016+, Office 365
If necessary, allow fallback to an earlier TLS version during the transition period.
5. Check for TLS 1.3 Usage
Once enabled, you can check TLS protocol analytics in server logs or traffic analysis tools to confirm clients are actually utilizing TLS 1.3.
Look for handshakes completing in 1-RTT along with TLS 1.3 cipher suites to confirm adoption.
6. Set Minimum TLS Version to 1.2
To improve security, disable the obsolete TLS 1.0 and 1.1 protocol versions if they aren’t necessary for legacy clients. Require at least TLS 1.2.
Following these steps will allow your services to benefit from improved security and performance with TLS 1.3!
Implementing TLS 1.3 – Server Changes
For website and server operators, what’s required to implement TLS 1.3?
Let’s go over the changes needed on the server side:
Handshake
- TLS 1.3 performs key exchange first, then server authentication. TLS 1.2 did these concurrently.
- The handshake uses 0-RTT mode and fewer round trips. TLS 1.2 required more round trips before application data could be sent.
- TLS 1.3 uses session resumption with PSKs by default. This is optional in TLS 1.2.
Cryptography
- Only forward-secret key exchange methods (DHE/ECDHE) are supported in TLS 1.3. Previous static RSA and DH modes are removed.
- It uses AEAD ciphers only e.g. AES-GCM and ChaCha20-Poly1305. TLS 1.2 supports multiple cipher types.
- The PRF hash is simplified to just use HKDF (HMAC-SHA256) rather than multiple options.
- Digital signatures use RSA-PSS rather than PKCS#1 v1.5 padding.
Alert Protocol
- TLS 1.3 defines new alert codes for common failure reasons. TLS 1.2 uses generic codes.
- HelloRetryRequest is a new TLS 1.3 alert message used in key renegotiation.
Record Protocol
- Sequence numbers are encrypted in TLS 1.3. They are in plaintext in TLS 1.2.
- Padding is removed in TLS 1.3. TLS 1.2 uses padding for constant length encryption.
- Compression is removed in TLS 1.3. TLS 1.2 enables optional compression.
Implementing TLS 1.3 – Client Changes
To take advantage of TLS 1.3 as a client, you may need to:
1. Update Your Operating System or Browser
Ensure you have a modern OS (Windows 10, macOS 10.15+, iOS 13+, Android 10+) or browser (Chrome, Firefox, Edge) with TLS 1.3 support.
Check for OS and browser updates that added TLS 1.3 capabilities.
2. Update TLS Libraries
For TLS client applications, the language / SDK may require updating:
- .NET Framework 4.7+, .NET Core 2.1+
- Java 11+
- Python 3.7+
- Go 1.12+
- OpenSSL 1.1.1+
Check your TLS library’s release notes for TLS 1.3 support availability.
3. Configure Min and Max TLS Version
Set the minimum TLS version to 1.2 and maximum to 1.3 (or no max). This avoids fallback to TLS 1.0/1.1 while allowing 1.3 usage.
In .NET for example:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls13;
4. Enable 0-RTT Handshakes
To reduce latency, enable 0-RTT handshakes to servers you reconnect to frequently when supported by the TLS library.
In .NET:
client.Connect(host, port, true, SslProtocols.Tls13); // Enables 0-RTT
This allows sending data faster on repeat connections.
5. Understand Compatibility Limitations
Some old platforms may not ever support TLS 1.3 – this includes Windows 7/XP, Java 8, OpenSSL 1.0.x, etc.
For these cases, you may need to maintain compatibility with TLS 1.2 or below.
With these client-side changes, your applications can start benefiting from faster and more secure connectivity powered by TLS 1.3!
Implementing TLS 1.3 – Load Balancer Considerations
When implementing TLS 1.3 for a website or service behind a load balancer, there are some additional factors to consider:
- Session resumption won’t work properly if connections get routed inconsistently to different web servers. Use a shared session cache like Memcached between the servers.
- Load balancers need to support forwarding the TLS 1.3 KeyUpdate message which allows refreshing session keys.
- 0-RTT data requires binding clients to the same web server consistently for improved performance.
- TLS termination can be done at the load balancer or on the web servers. There are tradeoffs around cacheability and server load.
- End-to-end encryption from clients to origin servers can be achieved using layer 7 load balancing without TLS termination.
Proper load balancer configuration is important to achieve the reliability and performance benefits of TLS 1.3 when scaling horizontally.
Using TLS 1.3 with HTTP/2 and HTTP/3
TLS 1.3 works well in conjunction with modern HTTP protocol versions:
HTTP/2 leverages features like connection multiplexing and request prioritization for better performance. TLS 1.3’s reduced round trips speed up the layer below.
HTTP/3 uses UDP via the QUIC protocol for reduced latency. Its 0-RTT handshakes integrate neatly with TLS 1.3 0-RTT for both latency and security.
Migrating to HTTP/2 and enabling HTTP/3 where supported allows sites to maximize performance gains through combined optimizations at both the TCP and HTTP layers.
Adoption of QUIC-based HTTP/3 is still early, but set to grow significantly in coming years as browser and CDN support increases.
Hardware Acceleration with TLS 1.3
To offload expensive TLS cryptography operations, hardware acceleration can be utilized:
- Dedicated cards like Intel QuickAssist can run TLS 1.3 cryptography and reduce server load.
- SmartNICs embed crypto acceleration into network cards and interface directly with web servers.
- GPUs can parallelize functions like AES encryption and DH key exchange.
- FGPAs can efficiently implement crypto algorithms in reconfigurable hardware.
- ASICs built specifically for high-throughput TLS processing are an option.
This becomes more beneficial with TLS 1.3’s increased use of ephemeral key exchange and forward secrecy algorithms.
Hardware acceleration prevents TLS processing from bottlenecking server resources like CPU cores and improves scalability.
Migrating from Older TLS Versions
To transition from TLS 1.2 or below to 1.3, a gradual approach is recommended:
- Run a TLS 1.3 and 1.2 parallel stack during the transition period to support legacy clients.
- Use server-side analytics to confirm clients are ready before disabling older TLS versions.
- For web servers, redirect HTTP to HTTPS sites to encourage TLS adoption.
- Set minimum version to TLS 1.2 with best practices (PFS, modern crypto) to improve security.
- Gradually remove support for TLS 1.0/1.1 as older clients drop off.
- Periodically reevaluate cipher suite selection and key sizes to stay current.
With care taken to ensure legacy functionality during the migration, sites can smoothly transition to TLS 1.3 at their own pace.
TLS 1.3 – Conclusions
TLS 1.3 represents a major advancement for transport layer security, bringing significant improvements in performance, security, and reliability. With wide support across major browsers and platforms, the stage is set for TLS 1.3 to become the standard for internet encryption. Sites and services can realize meaningful benefits by deploying TLS 1.3 including faster connections, improved user experience, stronger security guarantees, and greater resilience to attacks.
As client adoption grows, now is the time for servers to migrate to TLS 1.3 to take advantage of the faster, safer web. For any organization that runs an HTTPS website or service, implementing TLS 1.3 should be a top priority to unlock the next generation of transport security.
FAQs About TLS 1.3
How does TLS 1.3 improve security?
TLS 1.3 enhances security by mandating encryption for all data, removing obsolete cryptography, improving forward secrecy, and adding protections against replay attacks.
What are the main speed advantages of TLS 1.3?
TLS 1.3 significantly reduces connection latency by streamlining the handshake to 1-2 RTT and allowing 0-RTT data for repeat connections.
When did TLS 1.3 become an official standard?
TLS 1.3 was published as an IETF standard RFC in August 2018 after years of development.
What are the key compatibility concerns with TLS 1.3?
Mainly older operating systems like Windows 7 and obsolete browsers that do not support TLS 1.3 and rely on older protocol versions.
Do the major browser vendors support TLS 1.3?
Yes, TLS 1.3 has been supported in Chrome, Firefox, Safari, and Edge since 2018 making it widely usable across websites.
