The Three Promises

TLS exists to solve three problems. Every piece of the protocol, every algorithm, every message in the handshake, exists to deliver one of these three promises. If you understand these three problems deeply, everything else in this book will click into place.

Promise 1: Confidentiality

Without confidentiality, anyone between you and the server can read your data. Your passwords, your credit card numbers, your medical records, your private messages. All visible to anyone who can capture the packets.

The coffee shop eavesdropper sees everything. Your ISP sees everything. The compromised router three hops away sees everything.

Confidentiality means: only the sender and the intended recipient can read the data. Everyone else sees gibberish.

The tool that delivers confidentiality is encryption. We’ll cover symmetric encryption (AES) and asymmetric encryption (RSA, elliptic curves) in Part II.

Promise 2: Integrity

Confidentiality isn’t enough. Imagine your data is encrypted, so an eavesdropper can’t read it. But what if they can modify it?

Here’s a scary scenario. You’re transferring $100 to a friend through your bank’s website. The request is encrypted, so an attacker can’t read the amount. But what if they can flip some bits in the encrypted data? They don’t know what the bits mean, but if they change enough of them, maybe the amount changes from $100 to $10,000. Or maybe the destination account number changes to theirs.

This sounds far-fetched, but it’s a real class of attacks. If you can modify encrypted data without detection, you can cause serious damage even without reading it.

Integrity means: if anyone modifies the data in transit, the recipient can detect it. The data arrives exactly as it was sent, or the recipient knows something went wrong.

The tools that deliver integrity are hashing and message authentication codes (MACs). We’ll cover these in Chapter 4.

Promise 3: Authentication

Now imagine you have both confidentiality and integrity. Your data is encrypted and tamper-proof. But there’s still a problem.

How do you know you’re talking to the right server?

You type https://yourbank.com and a TLS connection is established. The data is encrypted. But what if the server on the other end isn’t actually your bank? What if an attacker intercepted your connection and is pretending to be your bank? They set up their own server, present their own encryption keys, and now you’re sending your password to the attacker, over a perfectly encrypted connection.

This is called a man-in-the-middle attack. The encryption is working perfectly. The integrity checks pass. But you’re talking to the wrong person.

Authentication means: the server proves it is who it claims to be. When your browser connects to yourbank.com, the server must prove that it actually controls that domain. If it can’t prove it, the browser shows you a warning.

The tools that deliver authentication are digital signatures and certificates. We’ll cover digital signatures in Chapters 9 and 10, and see how they’re used in cipher suites and the TLS handshake in Parts III and IV. For a deep dive on certificates themselves, see PKI From First Principles.

All Three Are Required

Here’s why all three matter:

Confidentiality without integrity: an attacker can’t read your data but can corrupt it
Confidentiality without authentication: your data is encrypted, but you might be sending it to an attacker
Integrity without confidentiality: no one can tamper with your data, but everyone can read it
Authentication without confidentiality: you know you’re talking to the right server, but everyone can read the conversation

You need all three. TLS delivers all three. And it does it using a combination of cryptographic tools that we’ll build up piece by piece in Part II.

A Map of What’s Coming

Here’s how the three promises map to the rest of this book:

graph TD
    A[Confidentiality] --> B[Symmetric Encryption - AES]
    A --> C[Key Exchange - Diffie-Hellman]
    D[Integrity] --> E[Hashing - SHA-256]
    D --> F[HMAC / AEAD]
    G[Authentication] --> H[Digital Signatures]
    G --> I[Certificates and CAs]
    B --> J[TLS Handshake]
    C --> J
    E --> J
    F --> J
    H --> J
    I --> J
    J --> K[Secure Connection]

Each tool solves one piece. The TLS handshake combines them all into a single protocol that runs in milliseconds. By the time we get to the handshake chapters, you’ll understand exactly why each message exists and what it achieves.

Let’s start building the toolbox.

Next: Hashing and Data Integrity

← Previous Chapter Next Chapter →