TLS and mutual TLS in practice

Every API call in this track travels inside an encrypted tunnel. At 2 a.m. Bot A opens one to the billing API. Your goal: know what TLS proves and what it does not. See how mutual TLS makes the caller prove itself. Spot the proxy mistakes that undo both.

What TLS gives you, and what it does not

The server proves who it is with a certificate. Then both sides agree on a fresh shared key. They switch to fast symmetric encryption. This is TLS (Transport Layer Security). It makes three promises:

• Secrecy. Nobody on the path can read the traffic.
• Integrity. Nobody can change a byte without being caught.
• Server identity. The client reached the holder of the certificate for that name.

TLS does not say which user sent a request. That is the job of your credential. It also does not protect data once it lands on the server.

The TLS 1.3 handshake

Before any HTTP flows, client and server run a handshake. These are the steps, in order:

1. ClientHello. The client lists what it supports, names the server it wants, and sends a one-time key share.
2. ServerHello. The server picks the options and sends its own key share. Both sides now compute the same secret, and it never crossed the wire. The one-time keys are thrown away, which gives forward secrecy. Stealing the server's key later does not unlock recorded traffic. From here on, everything is encrypted, even the certificate.
3. The server proves itself. It sends its certificate chain, a CertificateVerify signature made with the certificate's private key, and a Finished message.
4. The client checks. It checks the chain, the dates and the name (see certificates and chains of trust). Then it sends its own Finished.
5. Application data. Now the HTTP request, with its token, is sent.

Mutual TLS: the caller proves itself too

Mutual TLS (mTLS) adds the starred messages. The server sends a CertificateRequest. The client answers with its own certificate and its own CertificateVerify signature. That proves it holds the private key. With no certificate, the server can end the handshake before it reads a request.

A verified certificate is only half the job. The server must map it to a caller:

• Which issuers do you trust for clients? Only a CA you run for this purpose. Never "anything the operating system trusts". Otherwise a certificate from any public CA gets in.
• Which field names the caller? Pick one, such as a SAN URI like spiffe://example.org/billing. Match it exactly. Never use "contains" or "ends with".
• What may it do? The certificate says who. Your policy still decides what.

End TLS at the gateway, then pass identity on safely

TLS usually ends at a load balancer or API gateway. This is TLS termination. The gateway decrypts, inspects and forwards. It should open a new TLS connection to the backend, best with mTLS.

The gateway checked Sam's client certificate, but the backend never saw it. So the gateway tells the backend who called, in a header. A header is only text, and anybody can type one. Two rules make it safe.

1. The gateway removes or overwrites any incoming copy of the identity header, then adds its own. Keeping a copy that arrives does not fail safe.
2. The backend believes the header only from the gateway. Use mTLS between them, or a network path nothing else can reach. If not, an attacker types the header straight into the backend.