TLS and Public-Key Cryptography, Explained Without the Math

Slow asymmetric crypto agrees on a key; fast symmetric crypto protects the actual data.

The little padlock in the address bar hides one of the most elegant ideas in computer science. Every https://, every API call to a model provider, every database connection with TLS enabled, relies on a solution to a problem that sounds impossible: how do two machines that have never met agree on a secret, over a wire that anyone can read? This is a refresher on how they do it — and why the answer still governs uptime and security in modern cloud and AI systems.

Two kinds of encryption, and why you need both

Symmetric encryption uses the same key to encrypt and decrypt. It’s fast — modern CPUs have hardware instructions for AES — and it’s what protects the bulk of your data. It has one fatal weakness: both sides need the same key, and shipping a key over an open network means anyone listening now has it too.

Asymmetric (public-key) encryption uses a pair of keys: a public key that anyone can have, and a private key that never leaves the owner. Anything encrypted with the public key can only be decrypted with the private key. This solves key distribution — you can shout your public key across the internet — but it’s computationally expensive, too slow to use for a whole conversation.

TLS uses each for what it’s good at: asymmetric crypto to safely agree on a shared secret, then symmetric crypto to protect the actual traffic. That split, shown in the diagram, is the whole trick.

What the handshake actually does

1. ClientHello — the client says which TLS versions and ciphers it supports.
2. ServerHello + certificate — the server picks a cipher and sends its certificate, which contains its public key.
3. Verify the certificate — the client checks the cert is signed by a Certificate Authority (CA) it trusts. This is the step that answers “am I really talking to my bank, or to someone impersonating it?” Encryption without identity is worthless — you’d have a perfectly private conversation with an attacker.
4. Key exchange — using the server’s public key (modern TLS uses ephemeral Diffie-Hellman), both sides derive the same secret session key without ever sending it across the wire.
5. Secure channel — from here, everything is encrypted with the fast symmetric session key.

Two properties fall out of this that are worth naming. Authentication: the certificate proves identity. Forward secrecy: because the session key is ephemeral and derived fresh each time, capturing today’s traffic and stealing the server’s private key tomorrow still won’t decrypt it. That second property is why modern TLS insists on ephemeral key exchange.

The costs, because there are always costs

That handshake isn’t free. It adds one or two network round-trips on top of the TCP handshake before any data flows — which is exactly why connection reuse matters so much, and why TLS 1.3 cut the handshake down to a single round-trip (with a zero-round-trip resumption mode for repeat visitors). Terminating TLS also costs CPU, which is why load balancers and CDNs often terminate it at the edge.

Where this bites in production

Cryptography rarely fails because someone broke the math. It fails operationally:

• Certificate expiry is the number-one self-inflicted outage in this category. A cert quietly expires at midnight and every client refuses to connect. Automate renewal (ACME / Let’s Encrypt / your cloud’s cert manager) and alert on expiry dates — this is one of the highest-value, lowest-effort pieces of monitoring you can add.
• Chain and trust-store issues — a cert is valid but the client doesn’t trust its CA, or an intermediate cert is missing. “Works in my browser, fails in the container” is almost always a trust-store difference.
• Clock skew — cert validity is time-bounded, so a machine with a wrong clock rejects perfectly good certificates. NTP is a security dependency.

The AI/cloud relevance

mTLS is the backbone of zero-trust service meshes. Normal TLS authenticates the server. Mutual TLS makes the client present a certificate too, so both sides prove who they are. Service meshes (Istio, Linkerd) use mTLS to make every service-to-service call authenticated and encrypted by default — the practical foundation of zero-trust networking, and increasingly the way to control which workloads may reach a model endpoint at all.

AI endpoints are high-value targets, so identity matters more, not less. When I argue there should be no anonymous inference endpoints, TLS and mTLS are the mechanism. An inference endpoint without strong client identity is an open door to your most expensive compute and your most sensitive data flows. The certificate is how you know which agent or service is calling, which is the precondition for any real authorization or audit.

Agents multiply the cert surface. An agent calling many tools and APIs is establishing many TLS sessions, each with its own trust requirements. Every one is a potential expiry, a potential trust-store mismatch, a potential place identity breaks. The blast radius of “we forgot to renew a cert” grows with how many things your systems talk to — and AI systems talk to a lot of things.

The takeaway

You don’t need to implement Diffie-Hellman to operate secure systems. You need to understand the shape: asymmetric crypto solves key distribution and identity, symmetric crypto does the bulk work, and the certificate is the part that proves you’re talking to who you think you are. The math almost never breaks. The certificate lifecycle almost always does. Get identity and renewal right and TLS becomes the quiet, reliable foundation it was designed to be — including for the AI infrastructure you’re standing up on top of it.