The four-phase handshake, and the three threats it does and does not counter

Four phases, and what each one buys

The Handshake Protocol runs before any application data is transmitted. Its job is to let client and server authenticate each other and negotiate an encryption algorithm, a MAC algorithm and the keys that will protect everything the record layer subsequently carries.

Worked example. Omar's browser opens https://records.heron.example. TCP connects first — three-way handshake, no TLS involved yet — and only then does the TLS handshake begin.

Phase 1 — establish security capabilities. The client sends client_hello carrying five parameters:

• Version — the highest TLS version the client understands.
• Random — a 32-bit timestamp plus 28 bytes from a secure random number generator, 32 bytes in total. Its purpose is to prevent replay: because it is fresh, no recording of a previous handshake can be replayed into this one.
• Session ID — non-zero means "resume this session, or add a connection to it"; zero means "start a brand-new session".
• CipherSuite — a list of algorithm combinations the client supports, in decreasing order of preference, each element naming both a key exchange algorithm and a CipherSpec.
• Compression method — the compression the client can do.

The server replies with server_hello, carrying the same parameters — but as choices, not offers. Its Random is its own; the CipherSuite is the one it picked.

Phase 2 — server authentication and key exchange. What is sent depends on the key-exchange scheme, but typically the server sends its certificate, possibly additional key information, and possibly a request for the client's certificate. It always finishes with server_done, which says "that is all from me" — and then it waits.

Phase 3 — client authentication and key exchange. On receiving server_done the client verifies the server's certificate and checks that the server_hello parameters are acceptable, then sends its own key-exchange messages, plus a certificate of its own if one was requested. This phase is where the session's secrets are settled: the two sides now hold the same master secret, which neither of them transmitted.

Phase 4 — finish. The client sends change_cipher_spec, copies the pending CipherSpec into the current one, and immediately sends finished under the new algorithms and keys. finished is a MAC over the whole handshake transcript, so it verifies that key exchange and authentication actually succeeded and that nobody tampered with the negotiation. The server mirrors both messages: its own change_cipher_spec, then its own finished. Application data may now flow.

And the trick question that lives in Phase 4: change_cipher_spec is sent during Phase 4 but is not a Handshake Protocol message. It is sent by the Change Cipher Spec Protocol, which is a separate protocol with its own content type.

Three threats — and TLS honestly stops only two of them

Man-in-the-middle during key exchange. An attacker interposes, playing the server to the client and the client to the server, and runs two key exchanges instead of one. Against a bare key agreement — unauthenticated Diffie–Hellman, say — this works perfectly, because nothing in the exchange says who the far end is. TLS defeats it by authenticating the server's public key with a certificate signed by a trusted certification authority. The interposing attacker can generate a key pair, but cannot obtain a CA-signed certificate binding that key to records.heron.example. Note the condition carefully: the counter works only if the client actually validates the chain to a trusted root and checks that the certificate's name matches the host it asked for. A client that skips either check is back to unauthenticated Diffie–Hellman with extra steps.

Password sniffing. An eavesdropper on the path reads the login form as it goes by. TLS defeats this because the login POST is application data, and all application data is encrypted by the record layer using the write keys the handshake derived. The HTTP request line, the headers and the body are all inside the encryption; nothing readable is on the wire.

SYN flooding. An attacker opens TCP connections it never intends to finish — SYN after SYN with no final acknowledgement — leaving half-open connections that occupy the server's TCP state table for minutes and eventually crowd out legitimate clients. A vocabulary warning before you go further: this is the half-open state-table attack that Module 9 insists on calling SYN spoofing, because Module 9 reserves SYN flooding for the crude volumetric attack that simply exhausts the link's raw capacity. The assignment — and loose industry usage generally — calls the state-table attack SYN flooding, and that is the name used in this lesson. Answer in whichever vocabulary the question is written in, and say which you are using; the substantive point is unaffected either way. TLS does not counter this, at all. SYN flooding attacks TCP, which sits below TLS, and it does its damage before a single TLS byte is exchanged — the TLS handshake cannot begin until the TCP handshake completes, and completing it is precisely what the attacker declines to do. No TLS feature is even in a position to help. The defences are at the layer that is under attack: SYN cookies, which let the server avoid allocating state until the handshake completes; connection-rate limiting; and ingress filtering upstream to drop spoofed sources.

That third answer is a mark-winner, not an admission of defeat. A candidate who claims TLS stops SYN flooding has said something false about layering; a candidate who says TLS does not stop it, explains why, and names a defence that does, has demonstrated exactly the understanding the question is testing.