Skip to main content

TLS and cipher suites

Type: ExplanationCreated: Team: Security
draft

Overview

TLS is the protocol that secures network traffic. It does three things: encrypts the data so nobody can read it, authenticates the server (via certificates) so you know you're talking to the real one, and protects integrity so nobody can tamper with it undetected. HTTPS is just HTTP running over TLS.

A cipher suite is the agreed-upon bundle of algorithms a connection uses — one for exchanging keys, one for encrypting the data, one for integrity. The client offers a list, the server picks one, and that decides how the connection is protected.

That's the whole idea: TLS sets up a secure channel, and the cipher suite is the specific recipe of crypto used to do it. In practice you just pick a modern setup (TLS 1.3, fall back to 1.2) and let curated defaults handle the rest.

TLS versions

  • SSL 2.0 / SSL 3.0 — the predecessors to TLS. Both badly broken and deprecated; don't use.
  • TLS 1.0 (1999) and TLS 1.1 (2006) — officially deprecated in 2021. Avoid.
  • TLS 1.2 (2008) — still widely used and considered secure when configured well. The safe fallback.
  • TLS 1.3 (2018) — current best, faster handshake, forward secrecy mandatory, legacy cruft removed.

Cipher types

Symmetric ciphers use the same key to encrypt and decrypt. They're fast and do the heavy lifting of encrypting your actual traffic. AES and ChaCha20 are the ones in use today.

Asymmetric ciphers use a key pair — a public key and a private key — where what one encrypts only the other can decrypt. They're slow, so they're not used for bulk data; instead they handle the bootstrap: proving identity and safely agreeing on a symmetric key. RSA and the elliptic-curve algorithms (ECDSA, ECDHE) live here.

TLS uses both: asymmetric crypto to set up the connection, then symmetric crypto for the conversation itself.

A "cipher suite" is a bundle (not one algorithm)

This is the key idea. When two machines do a TLS handshake, they don't pick a single cipher — they agree on a suite of algorithms, one for each job. In TLS 1.2 a suite name spells out every choice. Reading the one from your scan:

So one suite encodes four decisions: how the two sides agree on a key (key exchange), how the server proves who it is (authentication), how the data is encrypted (bulk cipher), and how tampering is detected (the MAC/integrity check).

Why TLS 1.3 makes this all simpler

TLS 1.3 took a machete to the legacy options. It removed all the weak/legacy pieces — no CBC, no SHA-1 MACs, no non-forward-secret key exchange, no RSA key transport. The only bulk ciphers left are AEAD. So a TLS 1.3 suite name is much shorter because most decisions are already fixed:

That's the real reason "minimum TLS 1.3" eliminates CBC automatically — the spec simply doesn't contain a CBC option to negotiate. TLS 1.2, by contrast, still allows the old suites for backward compatibility, which is why you can offer both strong and weak ones at once (and why ordering — strong first — matters).