We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
This idea carries a full system design question on its own. Each walks through the full answer.
System Design Masterclass · Security Architecture
Free preview: the first 2 parts of this 6-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Security Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
In 2010, a Firefox extension called Firesheep made session hijacking trivially easy. Anyone on a coffee shop WiFi network could click one button and see every unencrypted session on the network. Facebook logins, Twitter sessions, Amazon cookies, all visible in a friendly sidebar. Click a name, and you were logged in as that person. No hacking skills required.
Firesheep was downloaded over a million times in its first week. It did not exploit any vulnerability. It simply listened to the network traffic that HTTP sent as plaintext. The fix was obvious: encrypt everything.
Encryption in transit protects data as it moves between two points. From browser to server, from server to database, from service to service. It prevents three threats: eavesdropping (reading the data), tampering (modifying the data in transit), and impersonation (pretending to be the server).
TLS (Transport Layer Security) is the protocol that makes this work. When you see in your browser, TLS is encrypting the connection. As of 2026, over 95% of web traffic is encrypted. Chrome and Firefox flag HTTP sites as "Not Secure." Let's Encrypt issues free certificates in seconds. There is no legitimate reason for a modern application to serve traffic over plain HTTP.
Three TLS configurations matter in production: TLS 1.2 (legacy), TLS 1.3 (modern default), and mTLS (mutual authentication for services).
TLS 1.2 was released in 2008 and supports 37 cipher suites, many of them weak. Its handshake takes 2 round trips (4 messages), adding 200-400ms on high- connections. Forward secrecy is optional: if you pick a cipher without ECDHE, a stolen private key can decrypt all past traffic. About 20% of the web still runs TLS 1.2 because of old clients and legacy infrastructure.
TLS 1.3 was released in 2018 and strips everything down to 5 strong cipher suites. The handshake completes in 1 round trip, saving 100ms per new connection. Forward secrecy is mandatory because every cipher suite uses ECDHE. 0-RTT resumption lets repeat visitors send data on the very first packet, though it carries a small replay risk. Cloudflare reported a 12.4% reduction in page load time after deploying TLS 1.3.
mTLS (mutual TLS) adds client certificate verification on top of standard TLS. In regular , only the server proves its identity. In mTLS, the client also presents a certificate. This is how service meshes like Istio and Linkerd encrypt all inter-service traffic in Kubernetes clusters. Every pod gets a short-lived certificate from a certificate authority (often SPIFFE), and mTLS is enforced automatically.