TLS binds key establishment to a verified peer

In Diffie-Hellman reasoning, each side sends a public value derived from a private exponent and combines the received value with its own secret. The algebra lets honest peers obtain the same shared value without transmitting that value directly. A passive observer and an active intermediary are different threat models: without authentication, an intermediary can substitute public values and establish a different shared value with each endpoint. Encryption on both resulting connections does not mean that the original peers authenticated one another.

TLS 1.3 can use ephemeral finite-field or elliptic-curve key agreement, and it also supports pre-shared-key modes. Here we focus on a certificate-authenticated handshake with ephemeral agreement. The shared value feeds a structured key schedule; it is not copied directly into an arbitrary application cipher. Real groups, public-value validation, randomness, transcript handling, and implementation quality matter. Small classroom arithmetic explains agreement but cannot establish a secure parameter choice or replace a maintained TLS implementation.

The server presents a certificate chain that the client evaluates against its trust configuration and expected service identity. CertificateVerify demonstrates possession of the corresponding signing key over a context-bound transcript representation. Finished authenticates the handshake transcript using a key derived by the protocol. These checks serve related but distinct purposes: a trusted-looking certificate alone does not prove possession of its private key, and an encrypted Finished alone cannot repair a deliberately disabled identity check.

The transcript binds negotiated parameters and earlier messages so that authenticated agreement concerns this handshake rather than an unrelated exchange. The application must still configure the intended reference identity and reject failed verification. A callback that accepts every certificate error can erase the trust boundary while leaving encryption operational. Also distinguish termination points: if a proxy completes TLS, it is the cryptographic peer on that leg. A separately protected proxy-to-origin connection has its own keys, identity checks, and failure policy.

After the handshake, authenticated encryption protects records against the protocol's stated disclosure and modification threats when its keys and assumptions remain sound. It does not validate a database query's tenant, make a requested operation permissible, or conceal data from the authenticated endpoint itself. Server-only TLS normally authenticates the server to the client; it does not by itself identify the application user. Authentication tokens, client certificates, and authorization rules require their own validation at the relevant boundary.

Use the queue lab to inspect a fictional handshake-work budget. Press Reset, set both arrival λ=4 and service μ=3, predict the backlog slope, then Play or Step. For a separate lower-load case, Reset again and set both λ=2 and μ=3 before predicting and playing. The fluid model starts with four work items; parameter edits retain elapsed time and recompute from that start. It contains no cryptography or handshake messages. Its purpose is to distinguish costly connection setup from the permissions of requests carried afterward.