TLS on the wire

What TLS actually promises

TLS (transport layer security) sits between TCP and the application. It takes a plain byte stream and gives back a protected one. Three separate promises, and it helps to keep them apart because they fail in different ways.

The third is the one people undervalue, and it is the hardest. Encrypting to an impostor is worthless, so most of TLS's complexity is about proving identity rather than about ciphers.

TLS 1.3, published in 2018, is the version to learn. It removed every legacy option that had caused a decade of vulnerabilities: no static RSA key exchange, no CBC mode ciphers, no compression, no renegotiation. If a configuration offers anything older than TLS 1.2, that is a finding rather than a preference.

The TLS 1.3 handshake, one round trip

Remember that TCP's own handshake has already cost one and a half round trips before TLS starts.

1. ClientHello. The client offers its supported TLS versions and cipher suites, sends a key share, meaning its half of an ephemeral Diffie Hellman exchange, and includes SNI (server name indication) naming which host it wants, plus ALPN naming which application protocol it intends to speak. 2. ServerHello. The server picks a version and cipher suite and sends its own key share. At this instant both sides can compute the same shared secret, so everything after this point is encrypted. 3. Encrypted extensions, certificate, certificate verify, finished. The server sends its certificate chain and a signature proving it holds the matching private key, all encrypted. 4. Client finished. The client validates the chain, confirms, and can send application data.

That is one round trip for TLS 1.3, against two for TLS 1.2. Resumption with a pre shared key can carry application data in the very first message, which is called 0-RTT and comes with the caveat that such data is replayable, so it suits idempotent requests only.

Two properties fall out of the design and both matter:

- Forward secrecy. The keys come from an ephemeral Diffie Hellman exchange and are discarded after the session. So an attacker who records the traffic today and steals the server's private key next year still cannot decrypt it. This is why static RSA key exchange was removed. - SNI is why one address can host many sites. The server must choose which certificate to present before it knows which site was wanted, so the client says it up front, in the clear.

What an observer on the wire can still see

This is the part most descriptions of HTTPS get wrong by omission. Encryption protects the payload, not the envelope, because the network needs the envelope to deliver anything at all.

So an observer knows you visited example.com and roughly how much you read there, and cannot know which page. That partial leak has two remaining plugs. ECH (encrypted client hello) encrypts SNI itself, which requires support on both ends and is still rolling out. And DoH or DoT from Lesson 8-1 hides the name lookup that preceded the connection.

Traffic analysis deserves a mention too. Sizes and timings alone can identify which video was streamed or which page of a known site was fetched, without any decryption, simply by matching patterns. Encryption is necessary and it is not invisibility.

openssl s_client -connect example.com:443 -servername example.com </dev/null

Certificate chain
 0 s:CN=example.com
   i:C=US, O=Let's Encrypt, CN=R11
 1 s:C=US, O=Let's Encrypt, CN=R11
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
---
SSL handshake has read 4021 bytes and written 391 bytes
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Verify return code: 0 (ok)

s: is the subject, meaning who the certificate is for, and i: is the issuer, meaning who signed it. Read upward and it is a chain.

Certificates, and what validation checks

A certificate binds a public key to a name, signed by a CA (certificate authority) your system already trusts. Trust is transitive along a chain:

ISRG Root X1          in your operating system's trust store
  signs -> R11        an intermediate CA
    signs -> example.com   the leaf certificate the server presents

The server sends the leaf and the intermediates. It does not send the root, because you must already have it, otherwise anyone could supply their own. What the client verifies, in order:

1. The name matches the host requested, checking the subject alternative name extension. The old common name field is ignored by modern clients. 2. The dates are valid, meaning now is between notBefore and notAfter. 3. The signature chain reaches a trusted root, with every link verified. 4. The certificate is not revoked, checked with OCSP stapling or a revocation list, though this step is the weakest link in practice. 5. Extensions are appropriate, so an intermediate is marked as a CA and the key usage permits what is being done.

The failure messages map to those steps exactly, which makes diagnosis quick.

Two closing points on trust. A certificate proves control of a name, not that an organization is honest, so a phishing site can hold a perfectly valid certificate for its own lookalike domain. And because any trusted CA can sign for any name, certificate transparency logs exist so domain owners can watch for certificates issued for their names without permission, and CAA records from Lesson 8-2 declare which CAs are allowed to issue at all.