HTTPS — TLS handshake, certificates, CA: Visual walkthrough

4.3.27 · D2 · Coding › Computer Networks › HTTPS — TLS handshake, certificates, CA

Hum ek puzzle solve kar rahe hain: do computers jo kabhi mile nahi unhe ek secret code share karna hai, ek aise wire par jo sab padhh sakte hain, aur yeh bhi sure karna hai ki woh sahi partner se baat kar rahe hain.

Step 1 — Naked wire (woh problem jo hume beat karni hai)

KYA. Situation draw karo kisi bhi cleverness se pehle. Ek client (tumhara laptop) aur ek server (bank.com) ek wire se jude hain. Us wire par baitha hai Eve, jo har byte padh sakti hai, har byte badal sakti hai, aur server ban bhi sakti hai.

KYUN. Tum defense design nahi kar sakte jab tak tum exactly nahi dekh lete ki attacker kya kar sakta hai. Jo bhi hum baad mein banayenge woh Eve ki teeno powers mein se kisi ek ka seedha jawab hai.

PICTURE. Wire par plain words chal rahi hain "PASSWORD = hunter2" aur Eve unhe clearly padh raha hai. Dhyan do ki wire pehle se khuli TCP connection ke upar chal rahi hai — TLS kabhi pipe nahi banata, woh sirf us pipe ko secure karta hai jo TCP ne diya.

Figure — HTTPS — TLS handshake, certificates, CA

Step 2 — Pehla idea: bas shared key se encrypt karo (aur yeh akele kyun fail hota hai)

KYA. Maano client aur server pehle se ek secret key $k$ share karte hain. Phir sab kuch easy hai: client message ko $k$ se scramble karta hai (yeh hai symmetric encryption, ek hi key scramble aur unscramble dono karta hai), aur Eve sirf gibberish dekhti hai.

KYUN. Symmetric encryption (jaise AES) fast hoti hai — web page ke megabytes ke liye perfect. Iseelie TLS hamesha bulk data ke liye ise hi use karega.

PICTURE. Step 1 jaisi hi wire, lekin ab plaintext ek lock se guzarti hai jis par $k$ likha hai aur noise ban ke nikalta hai. Eve noise padhti hai aur kuch nahi sikha paati.

Dikkat. Humne maana tha ki dono sides pehle se $k$ share karti hain. Woh kabhi mile nahi. Agar client $k$ ko wire par bhejna try kare, Eve Step-1 conditions mein padh legi. Toh poora puzzle ek sawaal par collapse ho jaata hai: do strangers ek public wire par secret kaise agree karte hain? Yahi agla step hai. (Symmetric vs Asymmetric Encryption dekho ki hum symmetric ko har jagah kyun nahi use kar sakte.)

Step 3 — Public mein secret agree karna: Diffie–Hellman

KYA. Yeh woh trick hai jo magic lagti hai. Dono sides publicly do numbers par agree karte hain: ek bada prime $p$ aur ek base $g$ . Client secretly ek number $a$ choose karta hai aur $A = g^{a} mod p$ bhejta hai. Server secretly $b$ choose karta hai aur $B = g^{b} mod p$ bhejta hai. Ab har koi doosre ki number ko apne khud ke secret se raise karta hai — aur dono same value par pahunch jaate hain.

KYUN yahi tool. Hume ek aisa operation chahiye jo aage easy ho lekin peechhe mushkil. $p$ mod par power tak raise karna woh operation hai: $g^{a} mod p$ compute karna quick hai, lekin $a$ ko $g^{a}$ se recover karna discrete logarithm problem hai — bade $p$ ke liye impossibly slow maana jaata hai. Yeh one-way property iseelie Diffie–Hellman kaam karta hai aur iseelie hum ordinary multiplication use nahi karte (jo reverse karna easy hai).

PICTURE. Do mixing bowls. Client aur server ek hi public paint $g$ se shuru karte hain, har koi apna private paint ( $a$ ya $b$ ) milaata hai, mixed bowls swap karte hain, phir apna private paint phir se milaate hain. Dono bowls aakhir mein same colour $g^{ab}$ ho jaate hain. Eve ne do swapped bowls dekhe lekin unhe un-mix nahi kar sakti.

Toh Step 2 ka "maano unke paas $k$ hai" ab earned hai: Diffie–Hellman public mein $k$ manufacture karta hai. Poori detail Diffie–Hellman Key Exchange mein hai.

Step 4 — Jo hole bacha hai: doosri taraf kaun hai?

KYA. Diffie–Hellman eavesdropping ko defeat karta hai — lekin impersonation ko nahi. Eve DH do baar run kar sakti hai: woh tumhare saath handshake karti hai server ban ke, aur asli server ke saath alag handshake karti hai tumhara ban ke. Woh beech mein baithti hai, decrypt aur re-encrypt karti rehti hai. Yeh hai man-in-the-middle (MITM) attack.

KYUN matter karta hai. Shared secret bekar hai agar tumne galat insaan ke saath share kiya. Step 3 mein humne eavesdropping beat ki; ab impersonation beat karni hai. Authentication ke bina confidentiality khokhi hai.

PICTURE. Wire beech mein Eve se cut hai. Uske paas do alag DH secrets hain — ek client ke saath, ek server ke saath — aur messages relay karti hai, sab kuch padhti hai jab woh usse guzarta hai.

Fix yeh hona chahiye ki client verify kar sake ki DH share $B$ sach mein bank.com se aayi hai Eve se nahi. Uske liye hume identity prove karne ka tarika chahiye aur message swap nahi hua yeh prove karne ka tarika chahiye — agla do steps.

Step 5 — Signatures: prove karo ki message kisi specific se aaya

KYA. Asymmetric keys introduce karo: ek pair — ek private key $K^{-}$ secret rakho, aur ek public key $K^{+}$ duniya ko do. Magic: sirf $K^{-}$ signature create kar sakti hai, lekin koi bhi $K^{+}$ se check kar sakta hai. Sign karne ke liye, server pehle message ko hash se chhota karta hai (ek one-way fingerprint, jaise SHA-256), phir us fingerprint ko $K^{-}$ se lock karta hai.

KYUN hash, aur KYUN yahan asymmetric. Hum pehle hash karte hain kyunki ek tiny fixed-size fingerprint sign karna sasta hai aur message mein koi bhi change fingerprint ko badal deta hai (yeh deta hai integrity). Hum asymmetric keys use karte hain kyunki hume chahiye "sirf ek specific party produce kar sake, sab verify kar sakein" — symmetric keys yeh nahi kar sakti (shared key ka matlab hai dono sides forge kar sakti hain). Digital Signatures & Hashing dekho.

PICTURE. Server apne DH share $B$ ko ek short fingerprint mein hash karta hai, private key se signature $σ$ mein seal karta hai. Client khud $B$ ko re-hash karta hai aur public key se seal check karta hai. Match ⇒ genuine; mismatch ⇒ tampered ya forged.

Lekin ek naya gap khulta hai: client ko kaise pata ki $K^{+}$ sach mein bank.com ka hai? Eve apni khud ki public key bhej sakti hai. Step 6 yeh last loop close karta hai.

Step 6 — Certificates aur chain of trust

KYA. Certificate ek chota document hota hai jo kehta hai "public key $K^{+}$ bank.com ka hai", khud Certificate Authority (CA) ki private key se signed. Tumhara browser ek trust store ke saath aata hai jisme CA ke root public keys install time par hi bake hote hain. Cert verify karna bas Step 5 ka Verify run karna hai CA ki public key se.

KYUN third party. Client ka bank.com se pehle koi relation nahi, lekin woh CA par trust karta hai (baked in). Trust signatures ke through transitive hota hai: root intermediate ke liye vouch karta hai, intermediate leaf bank.com ke liye vouch karta hai. Signatures ko root tak follow karna jis par tum pehle se trust karte ho — yeh hai chain of trust. Details Public Key Infrastructure (PKI) mein.

PICTURE. Teen cards ki ek staircase: leaf (bank.com), intermediate, root. Har card ka signature uske upar wale card ki public key se check hota hai, tab tak jab tak top card browser ke trust store mein pehle se bethe root se match na kare.

Step 7 — Freshness aur transcript binding (last polish)

KYA. Do loose ends. (a) Agar keys sirf DH secret se derive hoti, toh ek recorded purana session replay ho sakta tha. Toh har side ek fresh random nonce bhi daalta hai ( $r_{c}$ client se, $r_{s}$ server se) jo key ko season karta hai. (b) Early messages (ClientHello, cipher list) encryption shuru hone se pehle gaye — Eve unhe downgrade kar sakti thi. Toh har side ek Finished message bhejta hai: ek MAC jo ab tak ke poore transcript par compute hota hai.

KYUN. Nonces freshness guarantee karte hain — same password har session mein alag keys deta hai, replay ko khatam karta hai. Finished MAC guarantee karta hai ki negotiation khud tamper nahi hua: agar Eve ne koi bhi earlier byte edit kiya, dono transcripts differ honge aur Finished check fail ho jaayega.

PICTURE. Ek funnel: pre-master secret $+ r_{c} + r_{s}$ sab ek one-way box mein daale jaate hain jis par $PRF$ likha hai, bahar aate hain session keys. Neeche, dono transcripts hash hoke compare hote hain — equal matlab "koi tampering nahi, encryption on karo".

Ek-picture summary

Neeche har arrow ek dushman defeated hai. Ise upar se neeche padho: raw wire, phir har defense pehle wale par stacked, aakhir mein fast symmetric tunnel jo asli HTTP data carry karta hai.

Recall Feynman: plain words mein poora walkthrough

Do strangers ek crowded, pickpocket-bhari street par whisper karna chahte hain. Pehle unhe realize hota hai ki ek secret code sab fix kar dega (symmetric encryption) — lekin woh kabhi mile nahi, toh unke paas koi code nahi. Toh woh poori nazron ke saamne ek paint-mixing game khelate hain: har koi ek private colour milaata hai, bowls swap karta hai, phir se milaata hai, aur — amazing — dono bowls same colour ban jaate hain jo dekhne waale reproduce nahi kar sakte (Diffie–Hellman). Woh shared colour unka code ban jaata hai. Lekin ek clever pickpocket beech mein khada ho sakta hai aur dono ke saath alag-alag paint mix kar sakta hai. Roke ke liye, dukandaar ek ID card dikhata hai jo ek mayor ne sign kiya hai jis par stranger pehle se trust karta hai (certificate signed by a CA), aur paint bowl sign karta hai taaki koi use swap na kar sake (digital signature). Stranger mayor ki stamp check karta hai — asli dukandaar confirmed. Aakhir mein woh fresh random numbers daalpte hain taaki aaj ka code kal se alag rahe, aur har koi sab kuch repeat karta hai jo unhone suna taaki sure ho sake ki koi greeting edit nahi hui (nonces + Finished). Sirf tab woh apne fast secret code mein whisper shuru karte hain. Pickpockets ko gibberish dikhta hai.

Recall Quick self-check

Diffie–Hellman khud akele kaun sa dushman defeat NAHI karta? ::: Impersonation (MITM) — yeh sirf eavesdropping defeat karta hai; authentication ke liye tumhe certificates/signatures bhi chahiye. Message ko sign karne se pehle hash kyun karte hain? ::: Ek small fixed-size fingerprint sign karna sasta hai, aur message mein koi bhi change fingerprint ko badal deta hai, jo integrity deta hai. Keys har session mein alag kyun hoti hain? ::: Fresh random nonces $r_{c}$ aur $r_{s}$ jo PRF mein mix hote hain (plus forward secrecy ke liye ephemeral DH values).