TLS Handshake
Every account of this draws the message sequence and then calls the result fast. Two things in that diagram are countable and neither is usually counted. The first is how many round trips pass before a client may send application data: two in TLS 1.2, one in TLS 1.3, and none at all when a resumed connection carries early data. The second is how many of those messages cross in the clear, and the answer changes far more between the versions than the round trip does. Eleven of them are readable in a TLS 1.2 handshake, including the server's certificate. Two are readable in TLS 1.3, and both of them carry a key share, which is the part worth sitting with: the agreement is reached in messages an eavesdropper receives in full. This page models TLS 1.3 and is dated to it. The story starts twenty-three years earlier, with Netscape's SSL 2.0 of February 1995, and nothing between those two dates is modelled here.
New to what a handshake has to settle? Start here
Two machines that have never met want to talk privately over a path they do not control. Before any of the conversation can happen they have to agree a key neither has told the other, agree which algorithms they will use, and establish that the far end is who it claims to be. That negotiation is the handshake, and everything in it crosses the same untrusted path as the conversation it protects.
Messages go in flights: one side sends everything it can, then waits, because a message cannot be answered before it arrives. So the cost of a handshake is a count of those waits, and the second thing worth counting is which of the messages an eavesdropper can actually read. This page counts both. How the key survives being agreed in the open is a different machine's subject.
Hard, not impossible
Nothing in this topic is unbreakable, and that is a claim about these machines rather than about cryptography. Each of them rests on an operation that is cheap in one direction and expensive in the other, and expensive means a number of steps so large that doing them costs more than the secret is worth. The one-time pad is the standing exception: it is not hard to break, it is impossible, and it is impractical for almost everything, which is why the rest of this topic buys difficulty instead.
That makes every claim here a claim with a date on it. Secure means secure for this long, against someone with this much to spend, assuming nobody finds a shortcut. The machines in this topic each rest on one of those one-way operations, and each is worth asking the same question about: what exactly would an attacker have to do, and how much of it.
The machine for this idea on its own is Diffie-Hellman, if you would rather press it than read about it.
Everybody hears the conversation that agrees the key nobody else has
1 Round trips before a client may send application data, counted off the figure in each standard
Both standards print the message flow as a figure, so the number of round trips before a client may send application data is not an adjective. It is something you count off the page. Move the network round trip and the cost of each version follows from that one count and nothing else: no processing time is modelled here, which is why a round trip of zero costs zero.
| handshake | flights | round trips | before the first byte | figure |
|---|
2 Every message in the chosen handshake, and which of them an eavesdropper receives in full
The second countable thing is more interesting than the first. RFC 8446's figure marks which messages are protected: braces for the handshake keys, brackets for the application keys, and nothing at all for the two that are sent in the clear. TLS 1.2 has no such marking before ChangeCipherSpec, because there is nothing to mark. Choose a handshake and see what an eavesdropper receives in full.
| flight | from | message | an eavesdropper sees |
|---|
3 What removing each round trip cost, in the standard's own words
Nothing above is free. The standard says what the last round trip costs to remove, in its own words: A zero round-trip time (0-RTT) mode was added, saving a round trip at connection setup for some application data, at the cost of certain security properties.
The property in question is named in section 8: There are no guarantees of non-replay between connections.
Ordinary data is protected by the server's random value, and early data is sent before the client has seen one.
| handshake | round trips | what is given up |
|---|
These ran in this browser when the page loaded. Each claim, whether it held, and the number behind it.
| claim | held | measured |
|---|---|---|
| a full TLS 1.2 handshake is 4 flights and 2 round trips before the client can send application data | yes | counted off RFC 5246 Figure 1, where nothing is protected until ChangeCipherSpec |
| TLS 1.3 does the same work in 1, which is the round trip the version saved | yes | RFC 8446 Figure 1: the server's whole flight, certificate included, follows its ServerHello |
| and early data on a resumed connection is sent at 0 | yes | the RFC calls this saving a round trip at connection setup for some application data, at the cost of certain security properties |
| an eavesdropper receives 11 messages in full from TLS 1.2 and 2 from TLS 1.3 | yes | TLS 1.3 leaves only the two hellos unprotected; the server's certificate moved behind the handshake keys |
| and both key shares are among the messages sent in the clear | yes | which is the point: the agreement survives being overheard, and why that works is Diffie-Hellman's page, not this one |
| at 80 ms the three cost 160, 80 and 0 ms | yes | no processing time is modelled, so these are the count times the round trip and nothing else |
What is real here, and what is not
No cryptography happens here, and the key agreement is another machine's
This page computes nothing secret. It has no key exchange, no signature, no hash and no random value, and the test asserts the engine contains no arithmetic that could be one. What makes the agreement survive being overheard is the subject of Diffie-Hellman, which is built. This page is the protocol that carries such an exchange, negotiates which one, authenticates the party at the other end and hashes the whole transcript into the keys. If it ended up re-teaching the key exchange it would have failed.
The flows are the figures, with the optional messages included
Both figures mark several messages as optional or situation-dependent, and both are transcribed here with those messages present, because the question the second panel asks is what an eavesdropper can read when they ARE sent. A handshake without client authentication has fewer messages and the same round trip count. The counts of messages in the clear would be smaller; the difference between the versions would not.
Time is the count times one number, and real handshakes are slower
The milliseconds here are round trips multiplied by the round trip you choose. Nothing else is modelled: not the TCP handshake underneath, not certificate validation, not signature verification, not a revocation check, not the extra round trip a HelloRetryRequest costs when the client guesses the wrong group. Every one of those makes a real connection slower than this page says, and none of them changes the count that separates the versions.
Two flights of TLS 1.3 are drawn as three entries
RFC 8446's figure ends with an application data exchange after the client's Finished, and RFC 5246's does the same. This page treats that exchange as an entry in the list so it can say when the client may send, and counts it separately from the handshake flights, which is why TLS 1.2 is four flights here and not five. The round trip figures are unaffected either way.
The date is the document, and 1995 is in the prose rather than the era
The page models TLS 1.3, so the entry is dated to RFC 8446 of August 2018, on the same precedent as Compare and Swap taking the date of the manual and Context Switch the date of the machine. An earlier draft carried an era of 1995-2018 to say where the story starts. That is not what an era does here: a span sits on the chronology at its start, so the range would have placed this page among the machines of the mid-1990s and its card would have disagreed with where it sat. SSL 2.0 of February 1995 is named in the lede and cited to Hickman's draft instead, which is where it belongs. Nothing between those dates is modelled here.
Sources
- Eric Rescorla, The Transport Layer Security (TLS) Protocol Version 1.3, RFC 8446, August 2018. Figure 1 for the message flow and its protection notation; section 1.2 for the 0-RTT mode and what it costs; section 8 for anti-replay.
- Tim Dierks and Eric Rescorla, The Transport Layer Security (TLS) Protocol Version 1.2, RFC 5246, August 2008. Figure 1 for the four-flight full handshake, in which nothing is protected until ChangeCipherSpec.
- Kipp E. B. Hickman, The SSL Protocol, Internet-Draft, February 1995, for SSL 2.0, which the lede names as where this starts. Nothing on this page models it; it is cited so the date in that sentence has a document behind it.
- Logical Art, the studio this belongs to.