A Leaner, Faster, Safer Protocol
TLS 1.3, finalized in RFC 8446, was the most significant upgrade to transport layer security in over a decade. It wasn't just an incremental improvement — it was a fundamental rethink of the handshake process, the cipher suites, and the attack surface of encrypted connections.
If you're running infrastructure that serves HTTPS traffic, understanding TLS 1.3 helps you make informed decisions about compatibility, performance, and security posture.
What Was Removed (And Why)
One of the most impactful changes in TLS 1.3 was removing features. The protocol dropped support for:
- RSA key exchange: Static RSA key exchange doesn't provide forward secrecy. If the server's private key is ever compromised, all past sessions encrypted with it can be decrypted. TLS 1.3 mandates ephemeral key exchange (ECDHE), ensuring that past sessions remain safe even if keys are later exposed.
- CBC mode ciphers: Block ciphers in CBC mode were the source of numerous attacks (BEAST, Lucky13, POODLE). TLS 1.3 uses only AEAD ciphers (AES-GCM, ChaCha20-Poly1305), which authenticate and encrypt in a single operation.
- Compression: TLS-level compression enabled the CRIME attack. Removed entirely.
- Renegotiation: A complex feature that introduced vulnerabilities. Gone.
- Custom DHE groups: Weak Diffie-Hellman parameters (like 512-bit or 1024-bit groups) enabled the Logjam attack. TLS 1.3 uses standardized, strong groups only.
The Faster Handshake
TLS 1.2 required two round trips between client and server before encrypted data could flow. TLS 1.3 reduced this to a single round trip (1-RTT) for new connections, and zero round trips (0-RTT) for resumed connections.
The 1-RTT handshake works by having the client speculatively send key shares in its very first message, rather than waiting for the server to negotiate parameters. This shaves off tens of milliseconds per connection — which adds up significantly at scale.
0-RTT resumption is even faster but comes with a tradeoff: the early data sent in 0-RTT is replayable, meaning it's suitable for idempotent requests (like loading a webpage) but not for state-changing operations.
Simplified Cipher Suites
TLS 1.2 supported dozens of cipher suite combinations, many of which were insecure. Administrators had to carefully curate their cipher suite lists to avoid weak configurations. TLS 1.3 supports only five cipher suites, all of which are considered strong:
- TLS_AES_128_GCM_SHA256
- TLS_AES_256_GCM_SHA384
- TLS_CHACHA20_POLY1305_SHA256
- TLS_AES_128_CCM_SHA256
- TLS_AES_128_CCM_8_SHA256
This dramatically reduces configuration complexity and eliminates the possibility of downgrade attacks to weak ciphers.
Encrypted Handshake
In TLS 1.2, the handshake itself was largely unencrypted — certificate information was visible to anyone observing the connection. TLS 1.3 encrypts the handshake after the initial key exchange, including the server's certificate. This is a meaningful privacy improvement: passive observers can no longer see which certificate a server presents.
What This Means for Your Monitoring
While TLS 1.3 improves security at the protocol level, it doesn't change the fundamentals of certificate management. Certificates still expire, still need valid chains of trust, and still need to be monitored. In fact, the move toward shorter certificate lifetimes (partly enabled by the efficiency of TLS 1.3 handshakes) makes monitoring more important.
CertGuard checks not just expiration dates but also the TLS configuration of your endpoints, helping you ensure you're serving certificates over modern, secure connections.
Action Items
Ensure your servers support TLS 1.3 (most modern web servers do by default). Consider disabling TLS 1.1 and earlier if you haven't already — browser support for these older versions has been dropped. And keep monitoring your certificates, because the best protocol in the world can't save you from an expired cert.