The encyclopedia · Software & IT · Technical decision · 2015–2018
TLS 1.3 made security the faster option and every site adopted it
By pruning legacy ciphers and cutting a round trip, IETF made encryption both safer and quicker than before
IETF · Mozilla · Google · Cloudflare
the move
Through TLS 1.2, a new encrypted connection cost two round trips of handshake before any data flowed, and servers could still negotiate weak 1990s-era algorithms. Performance and security pulled in opposite directions, so old insecure modes kept getting used.
RFC 8446, published in 2018 after three years of IETF work, changed the math: clients now send a key share in their first message, so a full handshake takes one round trip and a resumed one takes zero; static RSA key exchange and non-AEAD ciphers were removed, and every handshake message after ServerHello is encrypted.
Mozilla shipped TLS 1.3 in Firefox 61, Google followed in Chrome, and Cloudflare's early deployment showed the same story everywhere: connections got faster and stronger at once. Within a few years the major web was on 1.3.
why it works
- One fewer round trip is a measurable latency win on every connection, including mobile
- Removing legacy ciphers eliminated the weak-negotiation attacks that plagued earlier versions
- Encrypting the handshake hid certificates and extensions that used to leak in plaintext
- The version-negotiation mechanism let clients and servers upgrade without breaking the ecosystem
what transfers
When security and speed align, adoption takes care of itself. The winning change wasn't a new cipher; it was deleting old ones so the secure path became the fast path.
what came after
TLS 1.3 became the dominant encrypted-web protocol across browsers, CDNs, and servers, and its 0-RTT resume mode helped latency-sensitive applications. Its design language — fewer options, forward secrecy by default, faster by construction — became the template for later protocol revisions like QUIC/HTTP/3.
references
spotted an error? The archive wants to know.