The TLS stack, sessions versus connections, and the six directional keys

Four protocols above one record layer — and HTTP is not above them

TLS is not a single protocol. It is a set of protocols running over TCP, and it is described as being organised as three protocols on top of TCP, deliberately simple and inexpensive to implement. Those three are the Handshake Protocol, the Change Cipher Spec Protocol and the Alert Protocol; a Heartbeat Protocol was added later. All of them sit on the Record Protocol, which sits on TCP, which sits on IP.

Here is the trap, and it is a layer question rather than a security question: HTTP sits at the same level as the three TLS control protocols, not above them. Application data is handed straight to the Record Protocol, exactly as an alert or a handshake message is. The Record Protocol does not know or care which of the four it is carrying — application content is opaque to TLS, and no distinction is made among the applications using it. That is why the same record layer secures IMAP and a web page without modification.

TLS can be deployed two ways: built into the protocol suite, in which case it is transparent to applications, or embedded in a specific package — which is why every browser and web server ships with it.

A session is not a connection

Worked example. Omar's browser opens https://records.heron.example and, to render the page, opens four TCP connections to the same server.

The first connection triggers a full handshake, and what the handshake creates is a session: an association between client and server that defines a set of cryptographic security parameters. The other three connections do not repeat that negotiation. They share the session's parameters, which is the entire reason sessions exist — to avoid renegotiating expensive security parameters for every connection.

So:

• A connection is a transport providing a suitable type of service. TLS connections are peer-to-peer and transient, and every connection is associated with exactly one session.
• A session is created by the Handshake Protocol, holds the cryptographic parameters, and can be shared among multiple connections.

Between one pair of parties there may be many simultaneous connections. Multiple simultaneous sessions between the same pair are possible in theory and not used in practice.

Six keys, and every one of them is named for the writer

When the handshake finishes, both sides derive a session's working secrets from the master secret together with the two hello randoms — the client's and the server's. What they derive is not one key but six parameters, three per direction:

The MAC keys authenticate; the write keys encrypt; the initialisation vectors seed the block cipher's mode. Each direction gets its own set, so the bytes flowing client-to-server are protected by different key material from the bytes flowing server-to-client. That is not decoration — reusing one key in both directions invites an attacker to reflect a captured record back at its own sender.

And now the naming rule, which is the whole examinable point: a key is named for who WRITES with it, never for who reads it. So the symmetric key that the client uses to encrypt, and that the server uses to decrypt, is the client write key — even though half its work happens at the server. Do not reason from "the server is decrypting, so it must be the server's key." Ask instead: who wrote this?

The master secret is not one of the six. It is the value all six are derived from, and it never encrypts anything itself.