Topic 6.3
HTTPS / TLS
In one line
TLS wraps HTTP: certificates prove identity, the handshake agrees on keys, and everything after is encrypted.
Think of it like this
Sending a sealed, tamper-proof envelope instead of a postcard. Anyone can read a postcard (plain HTTP) in transit; a sealed envelope with a wax seal that proves who sent it (HTTPS) can't be read or faked by anyone in between.
Key ideas
- 01
HTTPS = HTTP over TLS. Port 443.
- 02
Handshake in a nutshell: ClientHello → ServerHello+certificate → client verifies cert chain (CA trust) → key exchange (RSA / ECDHE) → session keys agreed → encrypted channel.
- 03
Two promises: confidentiality (nobody reads) and authenticity (you're talking to the real server — the certificate is what proves it).
- 04
Certificate chain: leaf cert ← intermediate CA ← root CA — browsers ship the roots.
- 05
mTLS (mutual TLS): the SERVER also verifies the CLIENT's cert — the internal-service security story (Phase 14).
- 06
Termination point matters in HLD: LB terminates TLS (read the traffic as plaintext) or end-to-end TLS (service-to-service mTLS).
Java / Spring map
- →
Spring Boot: server.ssl.* config; keytool to generate certs; RestTemplate trust config for mTLS.
Code & diagrams
Every message in the handshake, in order — this is the diagram interviewers actually want to see.
Explain without notes
Where does the browser get the 'padlock'? Which message in the handshake carries the proof?
Practice
Trace the full handshake with cert + key exchange in a diagram and label every cipher algorithm you know.
Trade-offs
- ↔
TLS termination at LB = simpler, but plaintext inside the DC — good for debugging, weak for compliance-heavy paths.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can handshake in prose and say what the certificate actually proves.