On this page
1. Why primitives are not enough
AES, RSA and SHA-256 are individually excellent. Combined carelessly, they produce systems that fail completely.
A protocol specifies exactly who sends what, in which order, and what each party checks before continuing. Most real-world breaks are protocol errors, not broken maths: a check skipped, a message accepted out of order, a downgrade permitted.
2. The man in the middle
Diffie–Hellman lets two strangers agree a secret over an open line. It does not tell either of them who they are talking to — and that gap is fatal against an active attacker.
Mallory sits between Alice and Bob. He runs one key exchange with Alice pretending to be Bob, another with Bob pretending to be Alice. Both ends believe the connection is secure. Both are correct — they are just secured to Mallory, who decrypts, reads, re-encrypts and forwards.
No amount of key length helps. The missing property is authentication.
3. Certificates and the trust problem
Authentication means binding a public key to an identity. A certificate is that binding, signed by a certificate authority your browser already trusts.
When you connect, the server presents a certificate; your browser checks the signature chain, the domain name and the expiry date. If the chain terminates in a trusted root, the key is accepted.
This moves trust rather than eliminating it. You now trust a few hundred certificate authorities, and a compromised or coerced CA can issue a certificate for any domain. Certificate Transparency logs exist precisely so misissued certificates become publicly visible.
4. The TLS handshake
TLS is the protocol behind every HTTPS page. Version 1.3 stripped out decades of accumulated weakness and reduced the handshake to one round trip:
ClientHello
The browser lists supported ciphers and sends a key share for the exchange.
ServerHello
The server picks a cipher, returns its own key share, and sends its certificate.
Verify
The browser validates the certificate chain and checks a signature covering the whole handshake — which is what defeats the man in the middle.
That final signature over the transcript is the load-bearing step. Without it the exchange is anonymous and Mallory walks in.
5. Forward secrecy
If a server used one long-term key to encrypt every session, stealing that key would expose every conversation ever recorded — including traffic captured years earlier.
Forward secrecy prevents this by generating a fresh ephemeral key pair for every session and discarding it afterwards. Compromising the long-term key lets an attacker impersonate the server in future, but not decrypt the past.
TLS 1.3 makes this mandatory. Given the "harvest now, decrypt later" strategy — recording traffic today to break once quantum computers arrive — it matters more each year.
Frequently asked questions
- What is a cryptographic protocol?
- A precise specification of which messages are exchanged, in what order, and what each party verifies before continuing. It turns individual primitives into a usable secure system.
- How does TLS work?
- The client and server exchange key shares, the server proves its identity with a certificate and a signature over the handshake, and both sides then derive symmetric keys for the actual data.
- What is a man-in-the-middle attack?
- An attacker relays messages between two parties while running separate key exchanges with each, so both believe they have a secure connection while the attacker reads everything. Authentication prevents it.
- What is forward secrecy?
- Using a fresh ephemeral key for every session, so that stealing the server's long-term key does not allow decryption of previously recorded traffic.