Encryption: SSL/TLS
HTTPS already named the shape of the problem: everything sent over plain HTTP travels as text anyone on the path can read, and TLS is what wraps it so they can't. What that article didn't do — deliberately, since it was about HTTP's behavior, not TLS's internals — is explain how a connection that starts with two strangers and no shared secret ends up, a few milliseconds later, with both sides holding an encryption key that nobody else on the path can derive. That's a genuine cryptographic problem, and the way TLS solves it is the actual subject of this article.
SSL, TLS, and why one name outlived the other
SSL (Secure Sockets Layer), developed by Netscape in the mid-1990s, was the original protocol for encrypting a connection above TCP. It went through several revisions, all of which are now considered broken and unsafe to use — SSL 3.0 was formally deprecated by the IETF in 2015 after the POODLE attack showed it could be forced into a compromised fallback mode. TLS (Transport Layer Security) is SSL's successor, standardized by the IETF starting with TLS 1.0 in 1999, and every version of it in use today is TLS, not SSL.
The name "SSL" never fully went away, though — it's still how the technology is described colloquially, in product names, and in casual conversation among engineers who mean TLS but grew up saying SSL. This course's own navigation reflects that: this article is titled "Encryption: SSL/TLS" precisely because both names point at the same underlying idea in practice, even though only one of them refers to something you should actually deploy. If a server still negotiates actual SSL today, that's a serious misconfiguration, not a naming quirk — modern TLS libraries disable SSL 2.0 and 3.0 by default specifically because both have known, practical breaks.
Two different encryption problems, two different tools
Encrypting a message so nobody but the intended recipient can read it sounds like one problem. It's actually two, and TLS uses a different cryptographic tool for each:
- Symmetric encryption uses a single shared key. The same key that encrypts a message also decrypts it, on either side. It's fast — algorithms like AES can encrypt gigabytes per second on ordinary hardware — but it has an obvious precondition: both sides need the same key before they can exchange anything securely. If they already had a secure way to share that key, they arguably wouldn't need TLS to establish one.
- Asymmetric encryption (also called public-key cryptography) uses a mathematically related pair of keys — a public key, which can be shared with literally anyone, and a private key, kept secret by its owner. Data encrypted with the public key can only be decrypted with the matching private key. This solves the bootstrapping problem symmetric encryption has: a server can publish its public key openly, and anyone can use it to send that server something only the server can read, without any prior shared secret at all.
Asymmetric encryption sounds like it should be the whole answer, and TLS does use it — but not to encrypt the actual HTTP traffic. Asymmetric algorithms like RSA are computationally expensive, often a hundred times slower than AES for the same amount of data, which makes them a poor fit for encrypting an entire web page's worth of images and scripts on every request. TLS's actual design uses asymmetric cryptography only to solve the key-exchange problem, then switches to fast symmetric encryption for the actual data — the best property of each tool, without paying the cost of either one's weakness.
Asymmetric crypto: slow, but needs no prior shared secret -> used to establish a key
Symmetric crypto: fast, but needs a shared secret first -> used to encrypt the actual traffic
Getting a shared key without ever sending it
The mechanism that lets two sides agree on a symmetric key, over a connection an eavesdropper is actively watching, without that key ever crossing the wire in a form the eavesdropper could use, is called a key exchange. Modern TLS uses a family of algorithms based on Diffie-Hellman, most commonly its elliptic-curve variant, ECDHE (Elliptic Curve Diffie-Hellman Ephemeral).
The core trick is a mathematical operation that's cheap to compute in one direction and computationally infeasible to reverse. Both the client and server generate their own private random value and derive a public value from it using that one-way operation; each side sends its public value to the other in the clear, over the connection an observer can see in full. Each side then combines the public value it received with its own private value, and — because of the specific mathematical relationship the algorithm relies on — both sides land on the exact same resulting number, despite having exchanged nothing but two public values that, on their own, don't reveal it. An observer who saw both public values exchanged in plaintext still can't feasibly compute the shared result, because doing so requires reversing the one-way operation that generated them.
That shared result becomes the input to deriving the actual symmetric session key both sides use for the rest of the connection.
Ephemeral keys and why "forward secrecy" is worth naming specifically
The E in ECDHE stands for ephemeral — a new key pair generated fresh for every single connection, used once, and discarded immediately afterward, never written to disk or reused for the next connection. This property has a name, forward secrecy, and it matters for a specific, concrete threat: what happens if a server's long-term private key is ever stolen.
Older key exchange methods derived the session key directly from the server's long-term RSA private key. If that key were ever compromised — stolen in a breach, extracted from an old backup — an attacker who had recorded encrypted traffic from any point in the past could retroactively decrypt all of it, since the same long-term key that would have decrypted last year's traffic was still valid. With ephemeral Diffie-Hellman, each connection's actual session key is derived from a temporary value that's thrown away right after — so even a full compromise of the server's long-term private key years later reveals nothing about a session that already ended, because the value that mattered for that session no longer exists anywhere to be recovered.
A stolen private key only endangers future connections it can be used to impersonate — not past traffic already protected by keys that no longer exist. This is precisely why RFC 8446 removed static RSA key exchange from TLS 1.3 entirely and made an ephemeral, forward-secret exchange mandatory for every connection, rather than an optional hardening step server operators had to remember to enable.
Cipher suites: the algorithms actually agreed on
A cipher suite is the specific combination of algorithms a TLS connection settles on — which key exchange method, which symmetric cipher, and which method for verifying data integrity. openssl on a Linux host lists the cipher suites its TLS library currently supports for TLS 1.3:
Reading TLS_AES_256_GCM_SHA384: AES_256 is the symmetric cipher and key length doing the actual data encryption; GCM (Galois/Counter Mode) is what makes it an AEAD (Authenticated Encryption with Associated Data) cipher — meaning it doesn't just hide the data, it also detects tampering, producing an authentication tag alongside the ciphertext that fails verification if a single bit was altered in transit; SHA384 is the hash function used elsewhere in the handshake for key derivation and the transcript hash, not for encrypting data itself. TLS 1.3 deliberately shrank the list of negotiable cipher suites compared to TLS 1.2 — RFC 8446 removed the ability to negotiate non-AEAD ciphers, static key exchange, and several older hash functions entirely, closing off whole categories of downgrade and misconfiguration that plagued earlier TLS versions.
What this doesn't cover yet
This article deliberately stayed at the level of the cryptographic building blocks — symmetric versus asymmetric encryption, why TLS uses both, how a shared key gets derived without being transmitted, and what a cipher suite actually names. It hasn't yet covered how a client knows it's actually talking to the real server and not an attacker who also knows how to run ECDHE perfectly correctly — that's a trust problem, not a math problem, and encryption alone doesn't solve it. Nor has it walked through the exact sequence of messages a real TLS handshake exchanges. Both come next: PKI and certificates first, since the handshake's authentication step depends on understanding what a certificate actually proves.