TLS & encryption in transit
In one line
TLS uses certificates and a key exchange to prove the server's identity and agree on a fresh shared key, then encrypts and authenticates every byte with fast symmetric encryption.
What it is
TLS (Transport Layer Security, the successor of SSL) is the protocol that secures HTTPS, secure email, database connections and most service-to-service traffic. It gives three guarantees: confidentiality (eavesdroppers see only ciphertext), integrity (any tampering is detected) and authentication (you are talking to the real server, and optionally the server knows which client you are).
It combines two kinds of cryptography. Asymmetric cryptography (public and private keys) is used during the handshake to verify the certificate and agree on keys. Symmetric encryption such as AES-GCM or ChaCha20-Poly1305 is then used for the data, because it is much faster.
A certificate binds a domain name to a public key and is signed by a Certificate Authority (CA). Browsers and operating systems ship a list of trusted root CAs and check the chain from the server's certificate up to one of them.
Why interviewers ask
Encryption in transit is a baseline requirement in every security review and system design. Interviewers ask about TLS to see whether you understand the handshake cost, certificates and chains of trust, where TLS is terminated, and concepts like forward secrecy and mutual TLS, rather than just saying 'we use HTTPS'.
How it works
- 1ClientHello: the client sends supported TLS versions, cipher suites, a random value, the server name it wants (SNI) and, in TLS 1.3, its ephemeral Diffie-Hellman key share.
- 2ServerHello: the server picks the version and cipher suite and sends its own key share. Both sides can now compute the same shared secret without ever sending it (ephemeral Diffie-Hellman, usually ECDHE).
- 3The server sends its certificate chain and a signature over the handshake made with its private key, proving it owns the certificate. It then sends Finished. In TLS 1.3 these messages are already encrypted.
- 4The client verifies the chain up to a trusted root CA, checks that the name matches and the certificate has not expired, checks the signature, then sends its own Finished. TLS 1.3 needs one round trip for all this; TLS 1.2 needed two.
- 5Application data now flows encrypted with symmetric keys derived from the shared secret, and each record carries an authentication tag so tampering is detected.
- 6Returning clients can resume with a pre-shared key; TLS 1.3 even allows 0-RTT early data, which is faster but can be replayed, so it should only carry idempotent requests.
Worked example · A TLS 1.3 handshake to bank.com with timings
- Round trip time to the server is 50 ms. TCP handshake: 0 to 50 ms.
- At 50 ms the client sends ClientHello with SNI bank.com and an X25519 key share.
- At about 75 ms the server replies with ServerHello and its key share, then the encrypted certificate chain (bank.com, signed by an intermediate CA, signed by a root CA), CertificateVerify and Finished.
- At 100 ms the client has both key shares, computes the shared secret, verifies the chain against its trusted roots and checks the name bank.com matches.
- The client sends Finished plus the encrypted HTTP request right away. The response arrives at about 150 ms: 3 round trips in total (TCP, TLS, HTTP). With TLS 1.2 it would have been 4.
- An attacker on the Wi-Fi sees the IP address, the SNI and packet sizes, but cannot read the URL path, cookies or body, and cannot change a byte without the connection failing.
Picture it
Two people meet and each shows a passport stamped by a trusted government (certificate and CA). They then use a clever trick, like mixing paint colours, to agree on a secret colour that an eavesdropper cannot work out (Diffie-Hellman). After that they talk in a code based on that secret (symmetric encryption) and seal every message with wax that shows any tampering.
Key patterns
Where to terminate TLS
When: Designing an ingress path
How: Terminate at the load balancer or CDN for central certificate management and L7 routing; re-encrypt to backends, or use TLS passthrough if the backend must hold the key.
Mutual TLS
When: Service-to-service or device authentication
How: Both sides present certificates; use an internal CA and short-lived certs, usually via a service mesh.
Forward secrecy
When: Protecting past traffic if a key is stolen later
How: Use ephemeral (EC)DHE key exchange, which TLS 1.3 requires, so recorded sessions cannot be decrypted with the server's long-term key.
Reduce handshake cost
When: Latency-sensitive clients
How: Keep connections alive, use TLS 1.3 and session resumption, and use HTTP/3 where QUIC merges transport and TLS handshakes.
Real-world use
Let's Encrypt and automatic certificates
Let's Encrypt issues free 90-day certificates verified through the ACME protocol, and tools like Certbot or Caddy renew them automatically, which made HTTPS the default for most websites.
TLS termination at load balancers
AWS ALB, NGINX and Cloudflare terminate TLS at the edge so certificates are managed in one place; many companies then re-encrypt traffic to backends for end-to-end protection.
Mutual TLS in service meshes
Istio and Linkerd give every service a short-lived certificate and use mTLS so each service proves its identity, enabling zero-trust networking inside a cluster.
Databases and internal traffic
PostgreSQL, MySQL and Redis support TLS connections, and cloud providers like AWS RDS let you require it, because internal networks are not automatically safe.
In a project
A security audit finds that your microservices talk to each other over plain HTTP inside the data centre, and certificates for public sites are renewed by hand and once expired in production.
- Automate public certificates with ACME (Let's Encrypt or the cloud provider's certificate manager) and alert 30 days before any expiry.
- Enforce TLS 1.2 as the minimum, prefer TLS 1.3, disable old cipher suites and add HSTS on public domains.
- Introduce mutual TLS between services through a service mesh, with an internal CA issuing certificates that rotate every 24 hours.
- Add policies so service A may only call service B if its certificate identity is allowed, and monitor handshake failures.
Impact: No more expiry outages, all internal traffic is encrypted and authenticated, and a stolen credential from one service no longer lets an attacker freely call others. The added latency is a few milliseconds per new connection, hidden by connection reuse.
Trade-offs
Use it when
- Always for traffic over the public internet
- Inside data centres and clouds for sensitive or regulated data (zero-trust networks)
- mTLS when services or devices must prove identity to each other
Avoid it when
- Rolling your own encryption protocol instead of TLS
- Using 0-RTT early data for non-idempotent requests like payments, because it can be replayed
- Disabling certificate verification in clients to 'make it work'; it removes the protection against impersonation
Cost: TLS 1.3 adds 1 round trip to a new TCP connection (TLS 1.2 adds 2); resumption can make it 0. Symmetric encryption itself costs very little CPU on modern hardware with AES instructions.
Common mistakes
- Saying TLS encrypts data with the server's public key: the public key is for authentication and signatures; data is encrypted with symmetric session keys.
- Calling it SSL as if SSL were still used; SSL 2 and 3 and TLS 1.0 and 1.1 are deprecated.
- Thinking HTTPS hides the domain you visit: the IP and usually the SNI host name are visible.
- Forgetting that a certificate is only trusted because a CA in the client's trust store signed the chain.
- Ignoring expiry and renewal, a very common cause of real outages.
Interview questions
Quick revision
- TLS gives confidentiality, integrity and authentication.
- Handshake: asymmetric crypto (certs, ECDHE); data: symmetric (AES-GCM, ChaCha20).
- TLS 1.3: 1-RTT handshake, 0-RTT resumption (replay risk); TLS 1.2: 2-RTT.
- Certificate = domain + public key, signed by a CA; verify the chain to a trusted root.
- Forward secrecy via ephemeral keys; mandatory in TLS 1.3.
- SNI tells the server which host name, so one IP can serve many certs.
- mTLS: both sides present certificates; common in service meshes.
- Automate renewal; expired certs cause outages.
Check yourself
1. What encrypts the bulk application data in a TLS session?
2. How many round trips does a full TLS 1.3 handshake add on top of TCP?
3. What does forward secrecy protect against?
4. In mutual TLS, what is different from normal HTTPS?
Saved on this device. Create a free account to keep it on every device.
Practise this with Sam
A real mock interview, out loud, with an honest scorecard. Free to start.