TLS Explained

TLS is the "S" in HTTPS, and AES vs RSA already covered the elevator-pitch version: an asymmetric algorithm establishes a shared secret, then a fast symmetric one handles the actual traffic. That version is close enough for "why does TLS use both," but it's not actually how current TLS works — and the gap between the simplified picture and the real one is exactly where forward secrecy, certificate validation, and cipher suite names come from.

What TLS is actually promising

Three separate properties, not one vague "it's encrypted": confidentiality (no one in the middle can read the traffic), integrity (no one can tamper with it undetected), and authentication (you're actually talking to the server you think you are, not an impostor). AES-GCM alone gets you the first two — AES Encrypt/Decrypt covers exactly why GCM's built-in authentication tag catches tampering. The third property, authentication, is where certificates and signing come in, and it's the part the "RSA encrypts an AES key" simplification skips over entirely.

The handshake, correctly this time

Modern TLS (version 1.3) doesn't use RSA to encrypt anything during the handshake at all — that mechanism, called RSA key transport, was real in TLS 1.2 and earlier, and RFC 8446 removed it completely. Instead:

The server's long-term private key (the one matching its certificate) never encrypts the session key in this flow — it signs part of the handshake instead, proving the server actually holds the private key that matches the certificate it just presented. That distinction — sign vs. encrypt — is the same one AES vs RSA draws in general; TLS 1.3 is a concrete case of RSA (or ECDSA) doing the signing job, not the key-transport job.

Why this change matters: forward secrecy

Because the Diffie-Hellman value is freshly generated for every single connection and discarded afterward, recording today's encrypted traffic and later stealing the server's long-term private key still doesn't decrypt anything — the ephemeral value that actually produced the session key is already gone and was never derivable from the long-term key in the first place. That property is called forward secrecy, and it's exactly what the old RSA key-transport mode lacked: since the client encrypted the actual pre-master secret directly with the server's long-term public key, a leaked private key years later could decrypt every past session ever recorded. This is precisely why TLS 1.3 doesn't just discourage the old mode — it removed the option to negotiate it at all.

Where the certificate and CSR actually fit

The signature the server produces during the handshake only means something if the matching public key is trustworthy — that's what the certificate establishes. CSR Generator builds the request a certificate authority signs; the CA's signature over your public key and domain name is what turns "here's a key I generated" into "a trusted third party confirms this key belongs to this domain." A browser validates the full chain — your leaf certificate, signed by an intermediate CA, signed by a root CA already baked into the browser or OS's trust store — before trusting any of it. One IP address can serve certificates for multiple unrelated domains because of SNI (Server Name Indication): the client states which hostname it wants in plaintext before the handshake's encrypted portion even begins, so the server knows which certificate to present.

Reading a cipher suite name

A TLS 1.2-style cipher suite name spells out every algorithm choice in one string:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
     |     |        |          |
     |     |        |          hash used in the handshake's own key
     |     |        |          derivation (HKDF/PRF) — not the data
     |     |        |
     |     |        bulk cipher for the actual traffic
     |     |        (AES-256, GCM mode — see AES Encrypt/Decrypt)
     |     |
     |     authentication: RSA signs the handshake
     |     (see RSA Key Pair Generator)
     |
     key exchange: Elliptic-curve Diffie-Hellman, Ephemeral
     (the forward-secret exchange described above)

TLS 1.3 cipher suite names got shorter — TLS_AES_256_GCM_SHA384, for instance — because key exchange and authentication are negotiated through separate extensions now rather than bundled into the cipher suite itself; only the bulk cipher and handshake hash remain in the name.

Common mistakes

• Assuming HTTPS means the data is safe everywhere. TLS protects data in transit only — see Encoding vs Encryption vs Hashing for why encryption at rest is a completely separate decision.
• Treating "valid certificate" as "trustworthy content." A certificate proves the site controls the domain and encrypts the connection — it says nothing about whether the site itself is legitimate or safe.
• Describing modern TLS as "RSA encrypts the session key." That was true for TLS 1.2's RSA key-transport mode, removed in TLS 1.3 — current best practice is ephemeral Diffie-Hellman for the reasons above.

FAQ

Is SSL the same as TLS?

SSL is the deprecated predecessor name — SSL 3.0 was replaced by TLS 1.0 in 1999, and every version since has been called TLS. "SSL certificate" is still common shorthand for what is, today, always actually a TLS certificate.

Is TLS 1.3 strictly better than 1.2?

Yes — a faster single-round-trip handshake, removal of the non-forward-secret RSA key-transport mode and several other legacy weak options, and a smaller, more carefully reviewed set of choices generally.

What does forward secrecy actually protect against, in one sentence?

A future compromise of the server's long-term private key from decrypting conversations that already happened in the past.

How does key derivation relate to HMAC?

TLS 1.3 derives its traffic keys using HKDF, an HMAC-based key derivation function — the same keyed-hash construction HMAC Generator computes directly, just applied here to turn one shared secret into several separate keys instead of authenticating a message.

Try it yourself

CSR Generator and RSA Key Pair Generator cover the identity side of this post — the key pair and certificate request behind the signature a real TLS handshake produces — and AES Encrypt/Decrypt covers the bulk-cipher side. All three run entirely in your browser.