10 Transport Layer Security (TLS): How the internet is secured

This chapter explains why the modern internet needs TLS to operate safely over hostile, untrusted networks. It frames TLS as the foundation that keeps online communication confidential, intact, and authentic by defending against eavesdropping, tampering, and impersonation. The narrative sets the stakes with everyday scenarios—public Wi‑Fi, routers you don’t control, and attackers in the middle—then positions TLS as the practical way to establish trust without needing a trustworthy network.

It then demystifies how TLS achieves that trust. Compared with retired SSL, TLS strengthens the handshake, negotiates strong cipher suites, and uses modern key exchange (commonly elliptic curve cryptography) so both sides derive a shared secret without transmitting it. Certificates and the public key infrastructure let clients verify server identity, while integrity checks detect any in‑transit changes. The chapter also distinguishes standard TLS from mutual TLS (mTLS), where both sides authenticate with certificates—vital for service‑to‑service security in APIs and microservices—while noting the added operational burden of issuing, rotating, and revoking client certificates.

Finally, the chapter turns to application: enabling TLS for public endpoints and mTLS inside systems. It recommends terminating TLS at a Kubernetes Ingress for simplicity and scale, centralizing certificate management (often automated with tooling) and leaving apps on plain HTTP internally, or adopting mTLS via a service mesh when stronger internal guarantees are needed. It contrasts common Ingress controllers, outlines when in‑app termination can still make sense, and stresses careful configuration and hygiene—sound cipher choices, correct hostnames, protected keystores, and relentless certificate lifecycle management—because small mistakes can undo otherwise robust protections.

When surfing the Internet from a public network, you never know who shares the network with you. For this reason, all communications need to be secured.

The internet is a massive, unpredictable network. When you send a message, it travels through many unknown devices and routes before reaching its destination, which is why encryption, like TLS, is essential.

The SSL handshake in action: Alice and Bob exchange supported encryption methods, validate identities using certificates, and securely agree on a shared secret used to encrypt all future communication.

In TLS, Alice and Bob agree on encryption methods, exchange certificates, and use elliptic curve cryptography (ECC) to securely generate a shared secret without ever sending that secret across the network.

Using color mixing as an analogy for key exchange in TLS: Alice and Bob each choose a private color, mix it with a public one, and exchange the results. They then mix again locally to arrive at the same final color without ever revealing their secret. An outsider, even if watching the entire exchange, can’t reconstruct the final shared secret.

Curve25519: A widely used elliptic curve in secure communication systems like WhatsApp and Signal. Its equation allows both high security and efficient performance, making it ideal for modern encryption on low-powered devices like smartphones.

In mutual TLS (mTLS), both Alice and Bob present valid certificates to prove their identities before establishing a secure connection. Once identities are verified, they use elliptic curve cryptography (ECC) to safely agree on a shared secret for encrypting their communication.

TLS protects against three major threats: eavesdropping (unauthorized listening), tampering (modifying data in transit), and impersonation (pretending to be someone else using fake credentials).

A man-in-the-middle attack using Cain & Abel: By impersonating the router, an attacker silently intercepts messages between users and the internet. The traffic is forwarded normally to avoid suspicion, but the attacker can read all data in and out.

With TLS enabled, intercepted messages are encrypted and unreadable to attackers. Even if someone tries to alter the message, the recipient will detect the tampering because the digital signature won’t match the sender’s certificate. This was TLS ensures both confidentiality and integrity.

Browsers indicate a secure TLS connection with a padlock icon next to the URL. Clicking the icon reveals certificate details, such as the issuing Certificate Authority, the site’s public key, and verification that your connection is encrypted and trustworthy.

Acme Inc. uses TLS to secure communication between users and the system via an API Gateway. For internal service-to-service communication, such as between billing, payment, order, and user services, mTLS is used to ensure both encryption and mutual authentication within the system.

• TLS protects data as it travels across untrusted networks by encrypting it, verifying the identity of the server, and ensuring the data hasn’t been changed along the way.
• TLS solves three major problems:
• eavesdropping (no one else can read the message
• tampering (no one can change it without being detected)
• impersonation (you know you’re talking to the real server)
• Before TLS, there was SSL - a now-retired, less secure version. TLS 1.3 is the modern standard, using faster and safer encryption methods like elliptic curve cryptography.
• mTLS (mutual TLS) extends TLS by requiring both sides to prove who they are. It’s often used in secure backend systems where services must trust each other explicitly.
• TLS is typically terminated at the Ingress level (e.g., using NGINX or Traefik) in Kubernetes. This simplifies certificate management and keeps service configuration clean.
• In special cases, Spring Boot apps can terminate TLS themselves using a configured keystore, though this approach is more complex to scale.

FAQ