TLS
TLS is the protocol that turns a plain network connection into an authenticated, encrypted, tamper-detecting channel. Its handshake lets peers agree shared symmetric keys and lets the client verify that the server controls the private key for a certificate valid for the requested hostname.
TLS is necessary because the network between a client and server is not a trusted pipe. Routers, proxies, Wi-Fi operators, compromised hosts, or malicious intermediaries may observe packets, alter responses, or pretend to be the server. Plain HTTP gives them readable bytes and no reliable way for the client to know who answered. TLS addresses confidentiality, integrity, and server authentication before application data is trusted.
The handshake combines key agreement with identity checking. In a typical modern setup, the client and server use ephemeral Diffie-Hellman, often ECDHE, to derive the same secret without sending that secret over the wire. The server also sends a certificate chain. The client verifies signatures up to a trusted root, checks the requested hostname, validity period, and revocation signals, then uses the handshake transcript to derive symmetric keys for the session.
A certificate is commonly misunderstood. It does not prove that a site is honest, safe, or owned by the company you hoped for. It proves that a public key was certified as belonging to a particular name, and that the peer can use the matching private key. A lookalike domain can have a valid certificate. A self-signed certificate can encrypt traffic, but ordinary clients will not trust it for public HTTPS.
TLS trades simplicity and transparency for security. There is handshake work, certificate lifecycle management, trust-store dependence, and failure modes around expiry, wrong hostnames, missing intermediate certificates, and broken revocation checks. Public-key operations are not used for every byte because they are too costly, so TLS uses them to establish keys, then protects application data with faster symmetric authenticated encryption. Operationally, the hard part is often configuration, not the cryptography.
Engineers meet TLS at load balancers, ingress controllers, CDNs, service meshes, databases, and client libraries. TLS may terminate at an edge proxy such as a CDN or application load balancer, with a separate connection to the backend, so it is not automatically end-to-end. In practice you configure certificates, renewal, hostname validation, protocol versions, and modes such as strict origin verification. For databases, settings like full verification matter because encryption without hostname checking can still allow impersonation.
Common questions
- What does the TLS handshake establish?
- It establishes shared symmetric keys for protecting application data, verifies the server’s certificate chain and hostname, and binds those results to the handshake messages so tampering is detected. The shared secret is derived through key agreement, not sent directly. After that, traffic is encrypted and authenticated with symmetric cryptography.
- What does a TLS certificate actually prove?
- A certificate proves that a trusted certificate authority signed a binding between a public key and a domain name, and the peer proves it controls the matching private key. It does not prove the site is morally legitimate, that the business is trustworthy, or that a similar-looking domain belongs to the organisation you intended.
- Is TLS end-to-end if my service uses HTTPS?
- It depends where TLS terminates. If a browser connects to a CDN, ingress controller, or load balancer, the protected channel may end there. The proxy can then open a different connection to the origin, either encrypted or plain. End-to-end protection requires checking every hop and how certificates are validated between them.
- Why is hostname validation so important?
- A certificate can be validly signed and still be for the wrong name. If a client accepts any trusted certificate without checking the hostname it meant to reach, an attacker with a certificate for some other domain can impersonate the target. Proper validation checks both the certificate chain and the requested hostname.