How TLS Works

4 min read

Why Do We Need TLS?

HTTP protocol transmits in plaintext by default. This means data in transit can be easily eavesdropped on and potentially tampered with by man-in-the-middle attackers.

To ensure security, we need encrypted communication.

If both parties directly agree on a key (symmetric encryption), if this key is intercepted during transmission, the encryption becomes useless.

If using public/private keys (asymmetric encryption), while solving the key transmission problem, there's still a risk of man-in-the-middle attacks (MITM)—an attacker can intercept requests, impersonate the server to the client, and impersonate the client to the server.

So we need to introduce CA (Certificate Authority). The server gives its public key to a CA for signing to generate a certificate, and clients verify the certificate to ensure the server's identity authenticity.

TLS (Transport Layer Security) has only two core goals:

  1. Identity Authentication: Verify the identity of the communication party (usually the server).
  2. Key Exchange: Securely exchange a symmetric key (Session Key) for subsequent efficient encrypted data transmission.

TLS 1.2 Handshake Process

Before TLS 1.3 became widespread, the internet primarily used TLS 1.2 protocol for security. Its handshake process requires two round-trips (2-RTT), relatively cumbersome.

Assuming a client wants to connect to a server:

  1. Client Hello: Client sends supported TLS versions, cipher suite list, and random number A.
  2. Server Hello: Server selects a cipher suite, generates random number B, and sends back its certificate.
  3. Key Exchange: Server calculates and sends key exchange parameters (Server Params) and requests client confirmation.
  4. Client Key Exchange: After validating the certificate, client generates its parameters (Client Params) based on the parameters and sends them to the server.
  5. Change Cipher Spec: Both parties use random numbers A, B and exchanged Params to calculate the final Session Key. Client notifies server "subsequent communication will be encrypted."
  6. Finished: Client sends a message encrypted with Session Key, server validates and replies with an encrypted message, handshake complete.

A major historical burden of TLS 1.2 is supporting RSA key exchange. This method lacks Forward Secrecy—if the server's private key is leaked in the future, attackers can decrypt all historically intercepted traffic.

TLS 1.3 Improvements

TLS 1.3, released in 2018, made major simplifications and security upgrades.

It deprecated RSA key exchange and other algorithms that don't support forward secrecy, mandating Diffie-Hellman (ECDHE) for key exchange. Because algorithm choices are fewer and standardized, clients don't need to wait for the server to "choose" an algorithm—they can calculate and send their own public key parameters when sending Hello.

This compresses the handshake to 1-RTT:

  1. Client Hello: Client sends supported algorithms, random number A, and directly attaches its public key parameters (Key Share).
  2. Server Hello + Finished: Upon receipt, server directly calculates Session Key, sends back server public key parameters, certificate, and encrypted Finished message.

0-RTT For recently connected servers, TLS 1.3 allows clients to use previously cached credentials to send encrypted HTTP requests (like GET /) while sending Client Hello. This greatly reduces latency but introduces replay attack risks, typically only open for idempotent operations.

mTLS (Mutual TLS) and Microservices

In browser-to-website scenarios, usually it's one-way authentication: client validates server certificate, server doesn't validate client (because the internet is open to everyone).

But in microservices architecture, inter-service calls need strict permission control. For example, Payment Service shouldn't accept arbitrary requests, only requests from Order Service.

This requires mTLS (mutual authentication). During handshake, not only does the server present a certificate, but it also requires the client to present a certificate. The server will verify:

  1. Whether the client certificate was issued by a trusted internal CA.
  2. Whether the identity identifier in the client certificate (like SPIFFE ID in SAN) is on the allowed access list.

In Kubernetes Service Mesh (like Istio), usually the Sidecar (Envoy) proxy automatically handles this logic. Application code can initiate HTTP requests as usual, and the Sidecar intercepts traffic at the network layer, automatically performing mTLS handshake and encrypted transmission, thus implementing Zero Trust architecture.

Summary

  • TLS 1.2: Requires 2-RTT handshake, some legacy algorithms don't support forward secrecy.
  • TLS 1.3: Simplified to 1-RTT, supports 0-RTT, mandates forward secrecy, faster and more secure.
  • mTLS: Used for mutual authentication between microservices, foundation of zero trust networks.
← Back to all blogs