Securing TCP Connections: TLS · Computer Networking Interactive

Section 8.5 secured one application. This secures every application that runs over TCP (Transmission Control Protocol) . It does so with the same primitives, arranged to survive four specific attacks on a byte stream.

Words you will meet

TLS (Transport Layer Security) — the standardised successor to Netscape’s SSL (Secure Sockets Layer) version 3.
Master Secret — one secret per session, from which every key is derived.
Pre-Master Secret — what the client actually sends; the Master Secret is computed from it.
Record — the unit TLS cuts the byte stream into, each with its own integrity check.
HMAC (Hashed Message Authentication Code) — the message authentication code standard from section 8.3.2.
Woman-in-the-middle — the book’s term for Trudy sitting in the stream, able to insert, delete and replace segments.
Nonce — the once-in-a-lifetime number from section 8.4, used here to make each session’s keys different.

Why this matters

TLS is not a curiosity. It secures nearly every commercial transaction on the Internet, it is supported by all popular browsers and servers, and hundreds of billions of dollars are spent over it every year.

But the reason it belongs here, one section below e-mail, is structural. Securing an application secures that application. Securing TCP secures everything above TCP, and TLS can be employed by any application that runs over it.

The interesting part of this section is not the cryptography — you already have all of it. It is watching four separate attacks on a byte stream get four separate answers.

Where TLS lives

Figure 8.24 — where TLS actually lives

Without TLSstep 1 of 3

An application opens a TCP socket and gets TCP's services: reliable, ordered byte delivery, and nothing else.

It is application-layer code. It is used as though it were transport.

Read all steps as text

Without TLS — An application opens a TCP socket and gets TCP's services: reliable, ordered byte delivery, and nothing else.
With TLS — a sublayer inside the application layer — The application includes the TLS libraries and opens a TLS socket instead. Technically all of this is application-layer code.
And from the developer's point of view, it is transport — The TLS API is similar and analogous to TCP's. A developer who swaps one socket for the other has changed a library, not a design. That is why TLS can be used by ANY application running over TCP, not only by the web.

TLS technically resides in the application layer: an application that wants it includes the libraries and opens a TLS socket instead of a TCP socket.

But the TLS API (Application Programming Interface) is similar and analogous to TCP’s. From the developer’s perspective it is a transport protocol that provides TCP’s services enhanced with security services. Swapping one socket for the other changes a library rather than a design.

almost-TLS

The book builds a simplified version first and calls it almost-TLS. It has three phases: handshake, key derivation, data transfer.

Figure 8.25 — the handshake, simplified then real

Three phases: handshake, key derivation, data transfer. This is the handshake.

message 6 of 6

Click any arrow to see what that message says and why it is sent.

Start with almost-TLS. Then switch: the real handshake adds algorithm negotiation, two nonces, and two messages at the end whose only job is to protect the messages that came before them.

Read this diagram as text

Bob — the client sends TCP SYN to Alice — the server. The ordinary TCP three-way handshake happens first. TLS runs on top of an established connection.
Alice — the server sends SYN ACK to Bob — the client.
Bob — the client sends ACK to Alice — the server.
Bob — the client sends TLS hello to Alice — the server. Now the TLS handshake begins.
Alice — the server sends certificate to Bob — the client. Alice sends her certificate, which contains her public key. Because a certification authority signed it, Bob knows the key really is Alice's — this is section 8.3.3 being spent.
Bob — the client sends EMS = K⁺_A(MS) to Alice — the server. Bob generates a Master Secret, used only for this session, encrypts it with Alice's public key, and sends the Encrypted Master Secret. Alice decrypts it with her private key. Now both of them, and nobody else, know the MS.

Lifelines, left to right: Bob — the client (host), Alice — the server (server).

The handshake does three things. Bob establishes a TCP connection with Alice, verifies that Alice is really Alice, and sends her a Master Secret.

Alice’s certificate is what makes the second possible — it was signed by a certification authority, so Bob knows the public key in it is hers. That is section 8.3.3 being spent, exactly as promised.

Key derivation could stop there: the Master Secret is shared, so it could simply be the session key. It is not, and the reason is a principle rather than a mechanism.

Four keys from one secret

It is generally considered safer for Alice and Bob to use different keys from each other, and different keys for encryption and for integrity. So the Master Secret produces four:

key	job
`E_B`	encrypt data going from Bob to Alice
`M_B`	the HMAC key for data going from Bob to Alice
`E_A`	encrypt data going from Alice to Bob
`M_A`	the HMAC key for data going from Alice to Bob

In almost-TLS this could be done by simply slicing the Master Secret into four. Real TLS is a little more involved, and adds two initialization vectors when the chosen cipher uses cipher block chaining — one for each direction.

Data transfer raises a question the byte-stream model does not answer. TCP carries a stream with no boundaries in it. If TLS encrypted each byte as it arrived and passed it straight to TCP, where would the integrity check go? Waiting until the end of the session to verify everything Bob sent is plainly useless.

So TLS breaks the stream into records. Each record gets an HMAC appended, and then the record and its HMAC are encrypted together.

Four attacks on a byte stream

Here is where the section earns its length. Each of these is a thing Trudy can do to a TCP stream, and each gets its own specific answer.

Four attacks, four defences

	Downgradeedit the algorithm list	Reorder or replay recordswithin one session	Replay the whole sessionon another day	Truncationend the session early
What Trudy does
Why it would work
What stops it
How that works

Cells marked ⓘ have a reason behind them — click to read it.

Each row is a thing Trudy can do to a TCP stream, and the specific piece of TLS that stops it. Click any cell.

Reordering, traced

Suppose Trudy swaps two records in the stream. Follow it:

TCP at Alice sees nothing wrong and passes both records up to TLS.
TLS decrypts both.
TLS checks each record’s HMAC — and each record is individually intact.
TLS passes both byte streams to the application, in the wrong order.

Every check passed. The application received corrupted data.

The fix is a sequence number, and where it is put is the clever part. Bob counts the records he sends, starting at zero. He does not put the counter in the record. He feeds it into the HMAC computation, so the HMAC is a hash of the data plus the key M_B plus the current sequence number.

Alice tracks Bob’s counter independently. A record arriving out of position is verified against the wrong number, and fails.

Two different replay attacks, two different defences

These are easy to confuse, and the book separates them carefully.

Replaying individual records inside a live session is stopped by sequence numbers.

Recording an entire session and replaying it days later is stopped by nonces. The Master Secret is derived from the Pre-Master Secret and both nonces, so Tuesday’s session and Wednesday’s have different keys. Tuesday’s records fail Wednesday’s integrity checks, and the bogus transaction does not succeed.

The record, and why three fields stay readable

Figure 8.26 — the TLS record

Click any box to read what that part of the message is for.

Every field, as text

The first three fields are NOT encrypted. Click each one — the reasons they must stay readable are what shape the rest of the protocol.

The type, version and length fields are not encrypted, and each has a reason.

Length must be readable because TCP delivers a byte stream with no record boundaries. The receiver uses this field to cut records back out of the stream — it cannot decrypt what it has not yet delimited.

Type must be readable for the same practical reason, and it carries the defence against the last attack.

Why closing a connection needs its own message

The naive way to end a TLS session is to close the TCP connection underneath it: Bob sends a FIN (finish) .

Trudy can send that FIN herself, in the middle of the session. Alice would believe she had received all of Bob’s data when she had received only part of it. That is the truncation attack.

So a record can be marked, in its type field, as the one that terminates the session. The field travels in the clear but is authenticated by the record’s HMAC, so Trudy can read it and cannot forge it. If Alice sees a TCP FIN without a closure record first, she knows something is wrong.

The real handshake

The real TLS handshake differs from almost-TLS in three ways, and switching the ladder above to its second scenario shows all of them.

Algorithms are negotiated, not fixed. TLS mandates no particular symmetric or public key algorithm. The client offers a list; the server chooses.

Both sides contribute a nonce, and both nonces feed the key derivation.

Two messages at the end carry no new information. Steps 5 and 6 are each side’s HMAC over all the handshake messages — and they exist because of step 1.

Why steps 5 and 6 are not redundant

At step 1 the client sends its list of supported algorithms in cleartext, because nothing has been agreed yet that could encrypt it. That list typically contains some strong options and some weak ones.

Trudy, sitting in the middle, can delete the strong algorithms, forcing the client and server to settle on a weak one that she can break later.

Steps 5 and 6 close that. Each side sends an authenticated digest of every handshake message it saw. If Trudy edited the list in flight, the two sides saw different handshakes, and the two digests disagree.

The defence works by making both parties prove what they remember. No message needs to be secret for that — it only needs to be unforgeable.

The mental model

TLS is the primitives of sections 8.2 and 8.3, arranged around one awkward fact: TCP delivers a stream, and cryptographic integrity needs boundaries.

Cutting the stream into records creates the boundaries. Everything else in the protocol repairs what that leaves exposed. A counter in the HMAC for order. Nonces in the key derivation for freshness. A type field for the end, and a digest of the handshake for the handshake itself.

Four attacks, four answers, and none of them needed a new cryptographic idea.

Check yourself

0 of 7 answered

1.Why does TLS break the byte stream into records rather than encrypting data as it arrives?
2.predictTrudy swaps two records in the TCP stream. Which check catches it?
3.The Master Secret is shared by both sides after the handshake. Why is it not simply used as the session key?
4.Steps 5 and 6 of the real handshake carry no new information. What are they for?
5.Nonces and sequence numbers both defend against replay. What is the difference?
6.Why must the record's length field remain unencrypted?
7.What is the truncation attack, and what stops it?

What to remember

The sequence number is in the HMAC, not in the record. Bob counts records and feeds the count into the integrity computation, and Alice tracks his counter independently — so a reordered record is checked against the wrong number and fails.
Nonces and sequence numbers stop different replays. Nonces make each session’s keys different, defeating a whole-session replay days later; sequence numbers defeat replaying individual records inside a live session.
Steps 5 and 6 protect step 1. The algorithm list must travel in cleartext, so Trudy can edit it — and each side sending an authenticated digest of every handshake message it saw is what makes that edit detectable.