HTTPS — TLS handshake, certificates, CA: Worked examples

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

Definition Teen notations jo is page par milenge

SNI = Server Name Indication — pehle handshake message mein ek field jo server ko batata hai ki aap kaunsa hostname chahte ho, taaki ek server jo kai sites host karta hai sahi certificate pick kar sake. Classic TLS mein ye cleartext mein travel karta hai.
PRF = Pseudo-Random Function — ek one-way "blender" jo ek secret plus kuch labelled inputs leta hai aur key material output karta hai. Isko same inputs do aur ye hamesha same bytes deta hai; lekin output jaanna aapko secret ke baare mein kuch nahi batata. TLS iska use karta hai taaki dono sides independently identical keys compute kar sakein bina unhe transmit kiye. Ye jo one-way idea iske upar rely karta hai, uske liye Digital Signatures & Hashing dekhein.
Concatenation bar $∥$ — jab aap $r_{c} ∥ r_{s}$ dekhte hain, to bar ka matlab sirf "in dono byte chunks ko end-to-end ek lambi string mein jodo" hai. Ye division ya absolute value nahi hai; socho jaise $r_{c}$ ke bytes ko $r_{s}$ ke bytes ke aage staple karna. Dono sides same order mein staple karte hain, isliye dono PRF ko identical input dete hain.

Scenario matrix

Neeche har cell ek class hai jo TLS session mein ho sakta hai. Jo worked examples follow karte hain unme har ek [Cell A2] jaisa tag hota hai taaki aap dekh sakein ki poora grid cover hai.

#	Cell class	Kya vary karta hai	Covered by
A1	Happy path	Sab kuch valid	Ex 1
A2	Certificate chain arithmetic	Signature chain ke upar verify karna	Ex 2
B1	Degenerate: broken chain	Missing/untrusted issuer	Ex 3
B2	Degenerate: expired cert	`notAfter` past mein	Ex 4
B3	Degenerate: domain mismatch	SNI (Server Name Indication) ≠ cert Subject	Ex 5
C1	Active attacker (MITM)	Attacker public key substitute karta hai	Ex 6
D1	Number-crunch: Diffie–Hellman	Chhota $p, g, a, b$ → shared secret	Ex 7
D2	Limiting behaviour: forward secrecy	Long-term key baad mein leak hoti hai	Ex 8
E1	Real-world word problem	Latency / round trips	Ex 9
E2	Exam twist + 0-RTT edge case	"Kaunsi guarantee fail hoti hai?"	Ex 10

Prerequisite threads agar koi cell shaky lage: TCP — three-way handshake, Symmetric vs Asymmetric Encryption, Diffie–Hellman Key Exchange, Digital Signatures & Hashing, Public Key Infrastructure (PKI), DNS, HTTP — methods, status codes.

Example 1 — Happy path [Cell A1]

Forecast: Kya bulk page data server ki public key se protect hogi, ya kisi aur cheez se?

Steps

Client → ClientHello random nonce $r_{c}$ aur cipher list ke saath. Ye step kyun? Dono sides ko parameters agree karne hain aur client randomness inject karni hai taaki session key unique ho (replay ko defeat karta hai).
Server → ServerHello ek suite pick karta hai, $r_{s}$ bhejta hai; phir apni cert chain (leaf + R3) bhejta hai. Kyun? Chain client ko authenticate karne aur authentication public key nikalne deti hai.
Client chain verify karta hai: leaf ki signature R3 ki public key ke against check hoti hai; R3 ki signature ISRG Root X1 ki public key ke against check hoti hai (jo pehle se trusted hai). Chain valid. Kyun? Trust signatures ke through transitive hota hai — neeche chain figure dekhein.
Key exchange: client ek pre-master secret banata hai, ise leaf ki public key se encrypt karta hai, bhejta hai. Kyun? Sirf asli shop.com ke paas matching private key hai, isliye sirf wahi decrypt kar sakta hai → identity prove karta hai aur ek secret share karta hai.
Dono derive karte hain $master = PRF (pre_master, r_{c} ∥ r_{s})$ (yaad karein bar $∥$ sirf dono randoms ko ek input mein glue karta hai), phir session keys, phir ChangeCipherSpec + Finished. (Upar wale box se yaad karein: $PRF$ woh one-way "blender" hai jo shared secret + dono randoms ko har side par identical key bytes mein convert karta hai, wire par kabhi bheja nahi jaata.) Kyun? Poore transcript par Finished MAC prove karta hai ki kisi ne pehle ke cleartext messages ke saath tamper nahi kiya.
Bulk HTTP ab ek symmetric key ke under flow karta hai (jaise AES-GCM). Kyun? Symmetric crypto asymmetric se bahut faster hai, isliye jab shared key safely bootstrap ho jaati hai to hum ise page ke har byte ke liye switch kar lete hain — "hybrid" idea ka action mein.

Figure — HTTPS — TLS handshake, certificates, CA

Figure walkthrough: teen boxes leaf → intermediate → root stack karte hain. Do kale "signed by" arrows upar ki taraf point karte hain: har certificate ki signature iske upar wale box ki public key se check hoti hai. Red leaf box (shop.com) woh hai jo aap trust karna chahte hain; right par red arrow dikhata hai aapka browser ise sirf isliye accept karta hai kyunki woh upward path pre-trusted root par khatam hota hai. Koi bhi arrow kaato aur trust collapse ho jaata hai.

Verify: Cert ki public key ek baar use hui, bootstrap karne ke liye. Bulk data derived symmetric key use karta hai — parent ke "hybrid" idea se match karta hai. Forecast answer: kuch aur (symmetric key), public key nahi. ✓

Example 2 — Chain signature arithmetic [Cell A2]

Forecast: Kya recovered $h^{'} = σ^{e} mod n$ exactly $65$ par wapas aayega? (Yahan $σ$ step 1 mein produce ki gayi signature value denote karta hai.)

Steps

Sign: $σ = 6 5^{413} mod 3233$ . Kyun? CA apne private exponent se sign karta hai — sirf wahi ye produce kar sakta hai.
Compute: $σ = 887$ . Kyun? Ye number child cert ke andar uski signature ke roop mein ride karta hai.
Verify: $h^{'} = 88 7^{17} mod 3233$ . Kyun? Public $(e, n)$ wala koi bhi private-key step undo kar sakta hai.
Compute: $h^{'} = 65$ . Kyunki $h^{'} = h$ , link authentic hai. Kyun? Matching hashes matlab body private-key holder ne sign ki thi aur alter nahi hui, isliye browser chain ki is rung ko accept karta hai.

$d = 413$ sahi key kyun hai: RSA ke liye hume $e \cdot d \equiv 1 (mod λ (n))$ chahiye, jahan (definition box se) $λ (3233) = lcm (52, 60) = 780$ . Check: $17 \cdot 413 = 7021 = 9 \cdot 780 + 1$ , isliye $17 \cdot 413 \equiv 1 (mod 780)$ . Woh congruence exactly wahi hai jo signing aur verifying ko cancel out karati hai.

Verify: $6 5^{413 \cdot 17} \equiv 65 (mod 3233)$ kyunki $413 \cdot 17 \equiv 1 (mod λ (3233) = 780)$ . Round-trip original hash return karta hai. ✓

Example 3 — Broken chain (degenerate) [Cell B1]

Forecast: Strong encryption present hai — kya connection succeed hota hai?

Steps

Client leaf → … → trusted root ka path banane ki koshish karta hai. Kyun? Authentication ke liye ek aisi link chahiye jo browser mein baked key par khatam ho.
Path CorpCA par ruk jaata hai, jise koi trusted root vouch nahi karta. Koi valid chain nahi. Kyun? Trust sirf un signatures ke through transitive hai jo ek known root tak pahunchti hain.
Browser SEC_ERROR_UNKNOWN_ISSUER ke saath kisi bhi bulk data se pehle abort karta hai. Kyun? Verified identity ke bina encryption hollow hai — ek MITM bhi isi tarah self-issue kar sakta hai.

Verify: Teen guarantees mein se kaunsi fail hui? Authentication. Confidentiality ka cipher theek tha lekin worthless hai jab aap nahi jaante kiske saath share kar rahe ho — parent ke "self-signed certs" mistake se match karta hai. ✓ (Check karne ke liye koi number nahi.)

Example 4 — Expired certificate (degenerate: time limit) [Cell B2]

Forecast: Kya achchi signatures ek out-of-date cert ko rescue karti hain?

Steps

Validity window check karein: kya aaj $[notBefore, notAfter]$ ke andar hai? Kyun? Certs expire hoti hain taaki ek compromised-then-rotated key hamesha ke liye reuse na ho sake.
$2024 - 06 - 01 > 2024 - 03 - 15$ → window ke bahar (expiry ke 78 din baad). Kyun? notAfter ke baad ke din exact degenerate case hain: crypto valid, time invalid.
Browser reject karta hai: CERT_HAS_EXPIRED. Kyun? Ek expired cert ek aisi key guard kar sakti hai jise owner pehle hi retire kar chuka hai, isliye ise trust karna rotation ke poore point ko defeat kar dega — browser gamble karne ki bajay refuse karta hai.

Verify: 2024-03-15 se 2024-06-01 tak days = 16 (March ka baki) + 30 (April) + 31 (May) + 1 = 78 days baad. Positive ⇒ expired. ✓

Example 5 — Domain mismatch (degenerate: SNI ≠ Subject) [Cell B3]

Forecast: Ek valid, trusted, in-date cert — surely ye theek hai?

Steps

Aapne jo hostname maanga tha (SNI = login.shop.com) usse cert ki SAN list se compare karein. Kyun? Ek cert specific names authenticate karta hai; galat name par valid signature phir bhi aap nahi hain.
login.shop.com na shop.com se match karta hai na www.shop.com se (koi wildcard *.shop.com nahi). Kyun? Sirf exact/wildcard matching — koi substring ya "same registrable domain" shortcut nahi.
Reject: SSL_ERROR_BAD_CERT_DOMAIN. Kyun? Aisa naam accept karna jise CA ne kabhi vouch nahi kiya, kisi bhi shop.com cert holder ko arbitrary subdomains impersonate karne deta, isliye browser exact/wildcard match par insist karta hai.

Verify: Guarantee jo fail hui: authentication (sahi owner prove hua, galat naam). Agar SAN *.shop.com hoti, to match ho jaata. ✓

Example 6 — Active man-in-the-middle [Cell C1]

Forecast: Woh wire control karti hai — kya woh aapka pre-master secret padh sakti hai?

Steps

Aap cert ki signature chain ko trusted root tak verify karte hain. Kyun? Ye exactly woh check hai jo key substitution ko catch karta hai.
Mallory ki cert uski key se sign hai, aapke trust store ke kisi CA se nahi → koi valid chain nahi (Ex 3 jaisa hi failure mode). Kyun? Woh CA signature forge nahi kar sakti (usse ek CA private key chahiye jo uske paas nahi hai).
Alternatively, agar woh self-signed cert par aa jaaye, browser use reject kar deta hai. Kisi bhi tarah handshake abort ho jaata hai; koi pre-master kabhi uske liye encrypt nahi hota. Kyun? Kyunki pre-master sirf cert verification pass hone ke baad bheja jaata hai — verified key nahi matlab client secret kabhi release nahi karta.

Figure walkthrough: aap (left) bank.com ki taraf ek plain ClientHello (black arrow, rightward) bhejte hain, lekin Mallory beech mein pehle answer karti hai. Red arrow aapki taraf wapas uski fake cert hai jo uski apni key carry karti hai. Red text neeche left side follow karein: aapka CA check fail hota hai, isliye red "handshake aborts" note wahan hai jahan attack mar jaata hai — Mallory kabhi pre-master secret receive nahi karti. Red highlights exactly attack ke do moving parts ko highlight karta hai: fake cert aur rejection jo use defeat karti hai.

Verify: Ek diwar jo MITM ko rokti hai woh hai CA signature check, encryption itself nahi. CA verification hata do aur Mallory jeet jaati hai — parent ke "cert solves who is the public key" ko confirm karta hai. ✓

Example 7 — Diffie–Hellman number-crunch [Cell D1]

Forecast: Kya Alice ka $B^{a}$ exactly Bob ke $A^{b}$ ke barabar hoga?

Steps

Alice bhejti hai $A = g^{a} mod p = 5^{6} mod 23$ . Kyun? Woh $a$ reveal nahi karti; sirf $g^{a}$ travel karta hai, aur ise invert karna discrete-log problem hai.
$5^{6} = 15625$ , aur $15625 mod 23 = 8$ . Isliye $A = 8$ .
Bob bhejta hai $B = g^{b} mod p = 5^{15} mod 23 = 19$ . Kyun? Symmetric role — uska secret bhi hidden rehta hai.
Alice compute karti hai $s = B^{a} mod p = 1 9^{6} mod 23$ . Kyun? $B^{a} = (g^{b})^{a} = g^{ab}$ .
Bob compute karta hai $s = A^{b} mod p = 8^{15} mod 23$ . Kyun? $A^{b} = (g^{a})^{b} = g^{ab}$ — same exponent, isliye same result.
Dono ko $s = 2$ milta hai. Kyun? Kyunki $g^{ab} = g^{ba}$ , dono independently computed numbers identical hone ke liye force hote hain — woh shared value session key ka seed banta hai, aur ye kabhi wire par nahi gaya.

Figure walkthrough: Alice (left) aur Bob (right) dono ek secret ( $a = 6$ , $b = 15$ ) rakhte hain jo unka box kabhi nahi chodta. Beech mein do black arrows wire par sirf yahi hain: public values $A = 8$ aur $B = 19$ . Har ek doosre ki public value ko apne secret par raise karta hai; do red arrows neeche red box par converge karte hain — shared secret $s = 2$ jo kabhi transmit nahi hua. Red box payoff hai: dono sides par identical, kisi bhi eavesdropper ko invisible.

Verify: $1 9^{6} mod 23 = 8^{15} mod 23 = 5^{6 \cdot 15} mod 23 = 2$ . Dono sides equal ⇒ shared secret kabhi bheje bina establish hua. ✓

Example 8 — Forward secrecy baad mein key leak ke under (limiting case) [Cell D2]

Forecast: Ek leaked long-term key — kya ek, dono, ya koi bhi past session nahi girta?

Steps

Case (a): recorded pre-master long-term public key ke saath encrypt hua tha. Leaked private key ke saath, attacker pre-master decrypt karta hai → session keys derive karta hai → recording padhta hai. Kyun? Session secret permanently ek long-lived key se tied tha, isliye woh key crack karna retroactively jo bhi usne protect kiya tha sab unlock kar deta hai.
Case (b): har side ne ek throwaway DH key use ki jo session ke baad discard ho gayi. Shared secret $g^{ab}$ kabhi long-term key ke under encrypt nahi hua aur ephemeral $a, b$ ab exist nahi karte. Kyun? Long-term key sirf handshake sign karti thi; usne kabhi secret protect nahi kiya, isliye ise leak karna $g^{ab}$ ke baare mein kuch reveal nahi karta.
Isliye attacker sirf (a) crack karta hai. (b) mein forward secrecy hai. Kyun? Use ke baad ephemeral keys delete karna matlab past traffic ke liye koi surviving door nahi bachta — exactly yahi "forward secrecy" aapko deta hai.

Verify: Sirf RSA-transport session (2 mein se 1) compromise hua hai — exactly isliye TLS 1.3 sirf ECDHE/DHE suites rakhta hai. Broken sessions ki count = 1. ✓ (VERIFY mein logic check.)

Example 9 — Round-trip latency word problem [Cell E1]

Forecast: Roughly TLS 1.3 kitna save karta hai — thoda ya almost aadha?

Steps

Ek round trip $= 2 \times 40 = 80$ ms. Kyun? Round trip wahan-aur-wapas hai.
(a) TLS 1.2: TCP (1 RTT) + TLS (2 RTT) $= 3$ RTT $= 3 \times 80 = 240$ ms. Kyun? Classic TLS ko cert/key-exchange bhejne aur confirm karne ke liye ek extra flight chahiye.
(b) TLS 1.3: TCP (1 RTT) + TLS (1 RTT) $= 2$ RTT $= 2 \times 80 = 160$ ms. Kyun? 1.3 key share ko ClientHello mein fold karta hai, ek round trip bachata hai.
Saving $= 240 - 160 = 80$ ms (ek poora RTT). Kyun? Kam "doosre side ka wait karna" cycles directly kam startup delay mein translate hoti hain, isliye high-latency links par 1.3 snappier feel hota hai.

Verify: $3 \cdot 80 = 240$ , $2 \cdot 80 = 160$ , difference $= 80$ ms. Saving exactly ek RTT ke barabar — as designed. ✓

Example 10 — Exam twist: "kaunsi guarantee fail hoti hai?" + 0-RTT edge case [Cell E2]

Forecast: Part 1 — kya koi TLS guarantee fail hui? Part 2 — kya "data immediately bhejo" risk-free hai?

Steps

Part 1 — confidentiality: traffic us server ko encrypt kiya gaya tha. Held. Kyun? Valid cert matlab ek real AES tunnel establish hua tha.
Part 1 — integrity: wire par koi tamper nahi. Held. Kyun? Finished MAC aur AEAD tags valid the.
Part 1 — authentication: cert ne prove kiya ki aap secure-paypa1.com ke real owner tak pahunche — exactly jinse aap unknowingly connect kiye. TLS ki teen mein se koi guarantee fail nahi hui; failure human/UX ki thi (look-alike domain), TLS ki job ke bahar. Kyun? TLS cert mein diye domain ko authenticate karta hai, woh domain nahi jो aap type karna chahte the — mismatch human ki aankhon mein hai, protocol mein nahi.
Part 2 — 0-RTT count: early data pehle client flight mein ride karti hai, isliye pehle app byte ke liye sirf TCP (1 RTT) + 0 TLS round trips of waiting = 1 RTT = 80 ms chahiye (normal 1.3 ke 160 ms vs, 1.2 ke 240 ms vs). Kyun? Previous session ke resumption keys client ko data encrypt karne dete hain server ke reply se pehle, isliye koi extra wait nahi chahiye.
Part 2 — kya kamzor hota hai: 0-RTT early data replayable hai — ek attacker woh pehla request capture karke resend kar sakta hai, aur ye forward-secret nahi hai. Isliye guarantees ki safety conditional hai: sirf idempotent requests (jaise GET, kabhi "transfer money" POST nahi) 0-RTT use karni chahiye. Kyun? Koi server round trip nahi matlab woh data se abhi tak koi fresh server randomness bound nahi hai, isliye early bytes ke liye uniqueness/replay protection kho jaati hai.

Verify: Part 1 → TLS-guarantees-failed count = 0. Part 2 → 0-RTT first-byte = $1 \times 80 = 80$ ms, aur ye exactly 80 ms faster hai normal 1.3 se (160 ms). ✓

Recall Quick self-test

Ek cert validly chained aur in date hai lekin shop.com ke liye issue hui hai jab aapne login.shop.com manga — accept karein? ::: Nahi — SAN/domain mismatch; authentication fail hoti hai (unless SAN *.shop.com ho). DH params $p = 23, g = 5, a = 6, b = 15$ ke saath, shared secret kya hai? ::: $s = 2$ . Long-term key agli saal leak hoti hai; kaunsa past session abhi bhi safe hai — RSA transport ya ECDHE? ::: ECDHE (forward secrecy). 80 ms RTT ke under, TLS 1.3 TLS 1.2 vs kitna save karta hai? ::: Ek RTT = 80 ms (160 ms vs 240 ms). "Transfer money" request kabhi TLS 1.3 0-RTT kyun use nahi karni chahiye? ::: 0-RTT early data replayable hai aur forward-secret nahi, isliye sirf idempotent requests safe hain.