TLS: design rationale and the socket abstraction

TLS was originally developed as Secure Sockets Layer (SSL) by Netscape. SSLv1 was very flawed and never saw real deployment; SSLv2 was deployed but also flawed; SSLv3 was finally sound enough for real use, and was standardised as Transport Layer Security by the IETF. SSLv3 itself has since been phased out to marginal usage, though “SSL” is still sometimes used out of habit to mean TLS. The latest version, TLS 1.3, was standardised in 2018.

Design rationale. The original case for SSL/TLS was to protect HTTP at the application layer. Its design goals:

• A generic security layer, informally “layer 4.5”, sitting between TCP and the application layer.
• TLS makes use of TCP underneath.
• Reuse of the socket abstraction: applications read from and write to TLS sockets instead of TCP sockets.
• Encryption, integrity and origin authentication made as transparent to the application as possible.

Why not place TLS at the application layer instead? Every application-layer protocol would have had to be individually extended to use it, and application-layer protocols are often text-based, which makes retrofitting security into them inefficient.

Recap: the socket abstraction. An application requests network communication from the kernel by defining its requirements, e.g. reliable and stream-based. A socket is an object the application writes into and reads from, much like a file descriptor. The kernel sends and receives over the network as either “streaming communication” (TCP: reliable, connection-oriented) or “datagram communication” (UDP: unreliable, message-oriented). A socket is an abstraction over source IP, destination IP, source port, destination port, and the protocol used. A raw socket is a socket with no layer-specific formatting done by the kernel at all; that work is left entirely to the application.

TLS sockets. Sockets are created with system calls, using a standardised API. TLS sockets are implemented in libraries: the library implements the ciphers and MACs, creates the socket with the kernel’s help, and hands the application a TLS socket that behaves like a normal TCP socket. A plain Python TCP client opens a socket like this:

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((HOST, PORT))

The common design wraps a TLS socket around that normal socket:

t = ssl.wrap_socket(s, ...)

Wrapping takes many parameters, and safe defaults matter: the lecture is explicit that safe defaults here are not optional.

Conceptual view of TLS. TLS assumes an X.509 PKI exists: the authenticating party must hold an X.509 certificate identifying it. Other variants, such as pre-shared key, exist but are rare. TLS authentication can be mutual, but commonly only the server authenticates to the client; the client application often authenticates to the server application separately, e.g. with a password. TLS 1.3 always uses authenticated Diffie-Hellman, which is what gives it forward secrecy; TLS 1.2 only strongly suggested this and also allowed classic hybrid cryptography, with a more complex key jointly created by both parties.

Conceptual protocol flow. The lecture works through the idea of TLS for server-only authentication with Diffie-Hellman. Let the client be $C$ and the server $S$, with secret Diffie-Hellman values $c$ and $s$ respectively:

C → S: N_C
S → C: N_S, Cert_S, g^s, Sig_S(N_C, N_S, g^s)

C → S: g^c, MAC_{K_{C,S}}(X)
(Let X := N_C, N_S, Cert_S, g^s, g^c, Sig_S(N_C, N_S, g^s))

S → C: MAC_{K_{C,S}}(Y)
(Let Y := (X, MAC_{K_{C,S}}(X)))

First half: negotiation. The client sends a nonce $N_C$ to identify a new session. The server picks its own nonce $N_S$ for that session, sends its certificate, picks a Diffie-Hellman value $g^s$, and signs everything sent so far.

Second half: authentication and key establishment. The certificate and signed nonce let the client authenticate $S$. From this point the client can derive the symmetric key $K_{C,S}$ and use MACs; it sends its own Diffie-Hellman value $g^c$. The server, now also holding the symmetric key, checks the correctness of the Diffie-Hellman exchange via the MAC and creates a final MAC over everything. When the client receives that final MAC, it is assured that no parameter along the way was tampered with.

This “two messages for negotiation, two for authenticated key establishment” shape recurs across many protocols, including the challenge-response protocols covered earlier.