Three guarantees, and only one of them is encryption

01 The idea

A private conversation needs three things, not one

Every packet you send crosses machines you do not own. The café router, your college’s NAT box, three or four ISP routers, and whatever sits in front of the server. Any one of them can read your bytes, change your bytes, or answer in the server’s place. So a connection over an untrusted network has to solve three separate problems, and it is worth being able to name all three, because candidates who name only the first one get caught by the follow-up.

The first is confidentiality: nobody in the middle can read what you sent. The mechanism is symmetric encryption of every record with a shared session key. The second is integrity: nobody in the middle can change what you sent without being caught. Encryption alone does not give you this, which surprises people. A ciphertext you cannot read is still a ciphertext you can flip bits in, and the receiver would decrypt it to something different and never know. The mechanism is a message authentication code, a short tag computed from the data and the key; change one bit of the record and the tag no longer matches, so the receiver throws the record away.

The third is authentication, and it is the one this lesson keeps coming back to: you are talking to the machine you meant to talk to and not to an impostor. The mechanism is a certificate, signed by an authority your machine already trusts. Say plainly what happens without it. If you encrypt to whoever answers, an attacker who intercepts the connection completes the handshake with you himself, opens a second connection to the real server, and forwards everything between the two. Both halves are properly encrypted. Both halves have valid integrity tags. He reads and edits every byte. Encryption without authentication is not weak security, it is close to no security, because it protects a conversation with the attacker.

Now the placement in the stack, which is the other half of the idea. TLS is not an application protocol. It is a layer that sits between the transport layer and the application: TCP hands it a byte stream, it hands the application a byte stream that happens to be private, and the application protocol above it does not change by one character. That is why HTTPS is exactly HTTP, with the same methods, the same status codes and the same headers, carried inside TLS on port 443 instead of in the clear on port 80. It is also why SMTP, IMAP, POP3, FTP, LDAP and DNS all have TLS variants without anybody redesigning their grammar. You wrap the pipe; you do not rewrite what flows through it.

02 Worked example

One browser, one server, one handshake

A browser opens https://www.example.com/. TCP has already finished its own three-way handshake to port 443, so a byte stream exists and nothing on it is private yet. What follows is a TLS 1.2 handshake compressed to five moves, and it is the same connection for the rest of the lesson: the message table in section 03 expands it row by row, the console in section 04 lets you step it, and every claim in the cheat sheet is checked against it. Read left to right, and watch which moves are readable by anyone on the path.

Two things in that sequence do most of the work, and node 3 is both of them. Take the key first. The word agreement is doing something specific and it is the point students most often get wrong. Nobody generates a session key and sends it. Each side picks a private value, publishes a value derived from it, and then does one calculation that turns its own private value plus the other side’s public value into a shared secret. Both calculations land on the same number. An observer who recorded every single byte of the handshake holds two public values and cannot get from them to that number. The session key is computed twice and transmitted zero times, which is why recording the traffic does not help you.

The second thing is the signature in node 3, and it is what stops the whole scheme from being a polite conversation with an attacker. Notice that a certificate on its own proves nothing. It is a public document; anyone can connect to www.example.com, take a copy of its certificate, and present that copy to you. What an impostor cannot do is produce a signature that verifies against the public key inside it, because that needs the private key. So the server signs its Diffie-Hellman public value, together with both random values from node 1, using the private key that matches the certificate. The client verifies that signature with the public key it just received. Only then does it believe anything.

Both random values are in that signature for a reason worth stating, because it is the difference between an answer and a memorised one. If the server signed only its own key share, an attacker could record a signed message from a real connection today and replay it in a fake connection tomorrow. Including the client’s fresh random makes the signature specific to this connection, so a recorded one is useless. That is the same reason the client random exists at all.

Finally, look at where the encryption starts. Moves 1, 2 and 3 are entirely in the clear. Anybody on the path can read which site you are contacting, which cipher suites your browser offers, and the full certificate the server sent back. The connection only goes dark at move 4. That is the ordering to remember for TLS 1.2, and it is precisely the part TLS 1.3 rearranges.

03 Mechanics

Every message, every guarantee, and every version that is now dead

Five tables, in the order the questions come. First the handshake in full, because "walk me through the TLS handshake" is asked directly and the follow-up is always which of those was readable. The last column is the one to study. Read down it and find the row where it flips.

Why the switch happens at message 8 and not earlier. The keys do not exist before message 6, so nothing before message 6 could have been encrypted. But that leaves an obvious hole: messages 1 to 7 were readable, so they were also editable. An attacker on the path could have deleted the strong cipher suites from the ClientHello and left only a weak one, and both machines would have negotiated the weak suite believing it was the best on offer. Finished closes that hole. Each side hashes the complete transcript of every handshake message it sent and received, and puts the result, keyed with the master secret, into its Finished. If the two transcripts differ by a single byte the check fails and the connection is torn down before any data moves. The handshake is in the clear, but it is not unprotected.

And why the slow cryptography is confined to the setup. The numbers make the design obvious. AES-128-GCM with the AES instructions present on every modern CPU processes on the order of a gigabyte per second per core. One RSA-2048 private-key operation takes on the order of a millisecond. Encrypting a 2 MB page with public-key operations is not slightly slower, it is not something you would attempt. So TLS spends its asymmetric budget on two things and stops: one signature to authenticate the server, and one key agreement. From message 8 onwards everything is symmetric, and the connection runs at line rate. When somebody asks why TLS uses both kinds of cryptography, that pair of sentences is the answer.

Now the three guarantees, each pinned to the mechanism that supplies it and the message it is delivered in. The last column is what an attacker does when that one row is missing, and it is the column that turns a memorised list into an answer.

Forward secrecy, and the one honest exception to "the key is never sent". Older TLS also allowed RSA key transport, where the client generated the pre-master secret itself, encrypted it with the public key from the certificate, and sent it across. That version really did put key material on the wire, protected by a key that lives on the server for years. Record the traffic, obtain that private key at any point in the future, and every past session opens. Ephemeral Diffie-Hellman has no such value: the private halves are thrown away when the connection closes and cannot be recovered from anything. This is why TLS 1.3 removed RSA key transport entirely, and why the honest form of the claim is: in the ephemeral key exchange that both versions use in practice, and the only one TLS 1.3 permits, nothing that crosses the wire is the key.

Reading a cipher suite name. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is four decisions written out. ECDHE is the key agreement, elliptic-curve Diffie-Hellman, ephemeral, so this connection has forward secrecy. RSA is the signature algorithm used to authenticate, which tells you what kind of key is in the certificate. AES_128_GCM is the bulk cipher, an AEAD mode that encrypts and produces the integrity tag in one pass. SHA256 is the hash for the key derivation. TLS 1.3 shortens the whole thing to TLS_AES_128_GCM_SHA256, because key agreement and authentication are negotiated separately in extensions and are no longer part of the suite name.

The certificate is the second half of the topic and the half that generates real support tickets. A certificate binds a set of hostnames to a public key, and it is trusted because of a chain: your server’s leaf certificate is signed by an intermediate CA, the intermediate is signed by a root CA, and the root is self-signed and already present in your operating system’s or browser’s trust store because it was shipped with it. The server sends the leaf and the intermediates; it does not send the root, because a root you receive from a stranger proves nothing and a root you already trust does not need sending. Here is what a browser then checks, and what it says when each check fails.

Versions next, and this is a table to get exactly right, because a candidate who says "we use SSL" has already told the interviewer something. SSL was the Netscape original; TLS is the IETF standardisation of it, and every version in production use today is TLS.

How TLS 1.3 gets to one round trip, and what it deleted to do it. In TLS 1.2 the client cannot send its key share until it has seen which group the server picked, which costs a whole round trip. TLS 1.3 has the client guess: it puts a key share for the group it expects into the ClientHello itself. The server usually accepts that group, replies with its own share in the ServerHello, and at that moment both sides can derive keys. So everything the server sends after the ServerHello is already encrypted, including the certificate, which was in the clear in TLS 1.2. The client then sends its Finished and its HTTP request in the same flight, which is why the count is one round trip and not two. The deletions are the other half of the story: no RSA key transport, no static Diffie-Hellman, no CBC modes, no RC4, no compression and no renegotiation, and the suite list shrank from hundreds to five. There is also 0-RTT resumption, where a returning client sends data in its very first flight using a key remembered from an earlier session, at the cost of no forward secrecy for that early data and no protection against it being replayed.

Finally, the payoff of TLS being a layer rather than a protocol. Every one of these keeps its own commands and its own grammar and runs them unchanged inside TLS. There are two ways to arrange that, and the difference is examinable: implicit TLS starts the handshake on the very first byte on a dedicated port, while explicit TLS begins as an ordinary plaintext session on the normal port and upgrades in place with a command such as STARTTLS.

Explicit upgrades have a weakness that implicit ports do not. On port 587 the first few lines of conversation are plaintext, and the server advertises STARTTLS in that plaintext. An attacker who can rewrite packets can delete that advertisement, the client concludes the server does not support TLS, and the session continues in the clear with neither side alarmed. On port 465 there is no plaintext conversation to edit. This is why the mail standards moved back towards implicit TLS, and why HSTS exists on the web: a 301 redirect from port 80 to port 443 still leaves one plaintext request that an attacker can intercept, and the Strict-Transport-Security header, plus the preload list shipped inside browsers, removes even that one.

Close on the limits, because "TLS protects everything" is the answer that gets picked apart. Here is what a passive observer captures from our connection, straight off the record layer. The first byte of every TLS record is its type, and the two after it are a version, so an observer can classify records without decrypting anything.

-- four of the TLS records of https://www.example.com/ , as captured16 03 01 00 c5   Handshake        ClientHello       readable: versions, random, suites, SNI=www.example.com16 03 03 00 51   Handshake        ServerHello       readable: chosen version and cipher suite16 03 03 0b 8e   Handshake        Certificate       readable: the entire X.509 chain, 2958 bytes of it17 03 03 01 f4   ApplicationData                    opaque: the 500-byte length covers the ciphertext and its 16-byte tag -- 0x16 = handshake, 0x17 = application data, 0x14 = change cipher spec, 0x15 = alert-- the two bytes after the type are a version; the two after that are the record length-- the ClientHello record reads 03 01 to get past old middleboxes; the real version is chosen inside the hellos

What TLS still does not hide. Three things, and you should be able to say all three. First, the server’s IP address, which sits in the IP header outside everything TLS touches; TLS cannot encrypt the address a packet has to be routed to. Second, how much data flowed and when. Record lengths are visible, timing is visible, and traffic analysis on those two alone can identify which video you streamed or which page of a site you loaded. Third, and most often forgotten, the hostname. The Server Name Indication extension exists because one IP address serves many sites and the server must know which certificate to present, so the name is sent in the ClientHello before any key exists, in the clear, in TLS 1.3 as much as in TLS 1.2. TLS 1.3 encrypting the certificate closes one leak and leaves this one wide open. Encrypted Client Hello is the fix for it and is still being rolled out. On top of that, the DNS lookup that found the address was probably plaintext on port 53 unless you were using DNS over TLS on 853 or DNS over HTTPS on 443.

05 Cheat sheet

The answers that get asked, and the wrong ones that get given

Every row is something you should be able to state in under ten seconds. The right-hand column is the specific wrong answer that gets written down, not a general caution.

06 Where & why

Four systems where this is a command you type

None of this is a diagram from a textbook. Every message in section 03 is something you can print on your own machine in one command, and three of the four systems below differ from the plain description in a way worth naming out loud.

07 Interview questions

What they ask, and what they follow up with

This topic is asked in two ways. In a networks round it is "walk me through the handshake". In a systems or security round it is "why is that safe", and the second one is where candidates run out of material after two sentences. Answer with mechanisms rather than adjectives: "a signature over both randoms" is an answer, "it is secure" is not.

08 Practice problems

Six to work on paper

Two of these are arithmetic and want a pen. Two are certificate failures, so write out the four checks a client makes before it trusts a server and find the one that fails, because in both of those exactly one thing is wrong and the other three are fine. The last two are about where in a session TLS starts, and what a connection gives up to start it early.