Trace TLS 1.3 through an access system

Protocol roles

A TLS 1.3 connection has a client and server. The client starts the handshake and validates the server identity. The server selects protocol parameters, proves possession of its private key when certificate authentication is used, and can request client authentication. Both endpoints derive traffic keys and protect application records after the handshake.

An identity-aware proxy creates at least two independent roles. It is the TLS server for the external client and a TLS client for an HTTPS upstream. These are separate channels. They can use different names, certificate authorities, keys, trust stores, and client-authentication rules. Record each channel as its own trust boundary.

RFC 9846 Section 4 defines the TLS 1.3 handshake. RFC 9525 defines how application clients verify service identities. X.509 path validation remains in RFC 5280 Section 6.

Message flow

1. The client sends ClientHello with supported versions, algorithms, key shares, and extensions. A resumed connection can also offer a pre-shared key and early data.
2. The server returns ServerHello with the selected parameters and key share. Both endpoints can now derive handshake traffic secrets.
3. The server sends encrypted handshake messages. These include EncryptedExtensions, its Certificate chain when used, CertificateVerify, and Finished.
4. The client validates the selected version, server certificate path, reference identity, certificate usage, signature, and transcript. It verifies the server Finished value.
5. The client sends its own Finished. It can also send Certificate and CertificateVerify when the server requests client authentication.
6. Both endpoints use application traffic secrets to protect records. Key updates can replace traffic keys without a new full handshake.

The certificate proves control of a private key for an accepted identity. The handshake transcript binds the negotiation and key exchange. The record layer then provides confidentiality and integrity for bytes between these two endpoints. None of these properties authorizes an HTTP action after termination.

Validation and failure cases

For every channel, test all of these conditions:

• Reject TLS versions and algorithms outside local policy. Confirm that a downgrade cannot silently select a deprecated version.
• Build and validate the certificate path to an explicit trust anchor. Reject an unknown issuer, invalid signature, expired certificate, or invalid usage.
• Match the exact service identity that the client intended to contact. A valid certificate for another name must fail.
• Verify possession with CertificateVerify and verify the handshake transcript with Finished.
• Reject missing client certificates when the route requires mutual TLS. A certificate chain alone does not authorize the certificate subject.
• Confirm that redirects and service discovery do not change the destination outside the approved name set.
• Confirm that plaintext cannot reach the upstream through another listener or bypass route.

RFC 9846 Section 2.3 states that 0-RTT data has weaker security properties. It is not forward secret and has no inherent cross-connection replay protection. Do not send non-idempotent or authorization-changing requests as early data unless the application has a tested replay defense. Disabling 0-RTT is a sound default for sensitive access paths.

Design tradeoffs and residual risk

TLS 1.3 reduces legacy protocol choices and encrypts more of the handshake, but it does not simplify endpoint ownership. Public certificate automation reduces manual work but increases the authority of DNS, ACME accounts, and deployment automation. Private trust anchors narrow issuance but add distribution and rotation work.

TLS termination gives a proxy the plaintext needed for routing and policy. It also places session data and private keys in that proxy's security boundary. A second authenticated TLS hop limits exposure after termination. It does not make the two channels one end-to-end channel.

Residual risks include compromised endpoints, stolen private keys, unsafe trust-store changes, accepted but unintended names, unprotected plaintext between hops, and replayed early data. Monitor the properties that configuration can change. Do not treat a successful handshake as proof that the protected application enforced authorization.

Pomerium boundary

Pomerium can terminate client TLS and use TLS for upstream connections. Operators own the public and upstream names, certificate sources, trust anchors, protocol settings, private-key custody, and direct-origin controls. Pomerium policy starts after the external channel reaches the proxy. The upstream application still owns request semantics and object authorization.

Exercise

Draw one production access path. Create one row for the client-to-Pomerium channel and one for each Pomerium-to-upstream channel. Record the TLS client, TLS server, intended reference identity, certificate issuer, trust store, private-key owner, termination point, permitted versions, client-authentication rule, and 0-RTT policy.

Run negative tests for a wrong name, unknown issuer, expired certificate, direct plaintext origin, missing client certificate, and replayed non-idempotent request. Save the command, observed alert or denial, and configuration version as evidence.

Evaluation checklist

• Can an engineer name both endpoints and the validated identity for every TLS hop?
• Does each client reject a valid certificate for the wrong service name?
• Are TLS 1.3 handshake authentication and record protection explained as separate properties?
• Is 0-RTT disabled or limited to replay-safe requests with a tested defense?
• Can no route reach the protected origin outside an approved authenticated channel?