HTTPS — TLS handshake, certificates, CA: Exercises

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

Definition Teen acronyms jo hum neeche baar baar use karenge (ek baar yahan define karte hain)

AEAD = Authenticated Encryption with Associated Data. Ek cipher mode (jaise AES-GCM) jo ek hi pass mein do kaam karta hai: data ko encrypt karta hai aur ek chota tag produce karta hai — ek fingerprint jo receiver ko kisi bhi tampering detect karne deta hai. "Associated data" wala part extra header info hota hai jo encrypt nahi hota lekin tag se covered zaroor hota hai.
SNI = Server Name Indication. TLS ke pehle message mein ek chota sa field jo batata hai ki client kaunsa hostname chahta hai (jaise bank.com). Ek IP par kai sites host ho sakti hain, isliye server ko pata karne ke liye SNI chahiye ki kaunsa certificate present kare.
PRF = Pseudo-Random Function. Ek one-way "blender": tum ise ek secret aur kuch public inputs dete ho, aur yeh key-material bytes generate karta hai jo random lagte hain. Same inputs → dono sides par same output, lekin tum ise ulta nahi chala sakte secret recover karne ke liye. TLS ise ek shared secret ko session keys mein badalne ke liye use karta hai.

Prerequisite links jo tum khula rakh sakte ho: Symmetric vs Asymmetric Encryption, Diffie–Hellman Key Exchange, Digital Signatures & Hashing, Public Key Infrastructure (PKI), TCP — three-way handshake, HTTP — methods, status codes, DNS.

Level 1 — Recognition

(Kya tum sahi idea ko point kar sakte ho jab tum use dekho?)

L1.1

HTTPS default par kaunse port par run karta hai, aur yeh kis do cheezein se bana hai?

Recall Solution

HTTPS = HTTP + TLS, port 443 par. Plain HTTP port 80 use karta hai; TLS woh encrypted, authenticated tunnel hai jiske andar HTTP bytes travel karti hain.

L1.2

Har TLS guarantee ko us cheez se match karo jo woh rokti hai: (a) Confidentiality (b) Integrity (c) Authentication

Ek café router chupke se page rewrite kar deta hai.
Wi-Fi par koi tumhara password padh leta hai.
Ek fake server bank.com hone ka natak karta hai.

Recall Solution

(a) Confidentiality → 2 (padhna ruk jaata hai; eavesdropper sirf ciphertext dekhta hai).
(b) Integrity → 1 (tampering MAC ya AEAD tag ke zariye detect hoti hai — yeh tamper-detection fingerprint is page ke upar define kiya gaya hai).
(c) Authentication → 3 (certificate identity prove karta hai).

L1.3

Mnemonic "Cool Servers Carry Keys, Change, Finish" mein, chhe handshake messages ko order mein naam batao.

Recall Solution

ClientHello → ServerHello → Certificate → Key exchange → ChangeCipherSpec → Finished.

Level 2 — Application

(Ek rule ko ek concrete case par apply karo.)

L2.1

Ek server cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 offer karta hai. Ise apne chaar kamon mein split karo.

Recall Solution

ECDHE — key exchange (ephemeral Diffie–Hellman → forward secrecy deta hai).
RSA — authentication (certificate RSA se sign/verify hota hai).
AES_128_GCM — bulk symmetric cipher (fast, actual data encrypt karta hai; GCM ek AEAD mode hai, toh yeh integrity tag bhi produce karta hai).
SHA256 — hash jo PRF aur MAC ke andar use hoti hai. Notice: do alag keys involved hain — RSA/ECDHE sirf bootstrapping karta hai, AES heavy lifting karta hai. Yeh hybrid design hai.

L2.2

Tiny numbers ke saath Diffie–Hellman. Public prime $p = 23$ , generator $g = 5$ . Alice ka secret $a = 6$ , Bob ka secret $b = 15$ . Yahan $g^{a} mod p$ ka matlab hai "g ko a ki power tak raise karo, phir p se divide karne ke baad remainder lo" — ek ghadi jo $p$ par wrap ho jaati hai. Public values $A, B$ aur shared secret $s$ compute karo.

Recall Solution

$A = g^{a} mod p = 5^{6} mod 23 = 15625 mod 23 = 8$ .
$B = g^{b} mod p = 5^{15} mod 23 = 19$ .
Alice compute karti hai $s = B^{a} mod p = 1 9^{6} mod 23 = 2$ .
Bob compute karta hai $s = A^{b} mod p = 8^{15} mod 23 = 2$ . Dono ko $s = 2$ milta hai bina kabhi bheja — yahi DH ka jaadu hai.

Neeche diya figure padho taaki samajh aaye ki kyun dono same $s$ par land karte hain. Upar ke do lavender/mint boxes follow karo: yeh secrets $a$ aur $b$ hain, jo kabhi apne owner ko nahi chhodte. Har secret neeche ek public half ( $A = 8$ , $B = 19$ ) mein jaata hai jo bheja ja sakta hai — beech mein coral arrows dikhate hain exactly kya eavesdropper dekh sakta hai. Ab dono diagonal arrows ko yellow box mein trace karo: Alice received $B$ ko apne secret se raise karti hai ( $B^{a}$ ), Bob received $A$ ko apne secret se raise karta hai ( $A^{b}$ ). Kyunki $g^{ab} = g^{ba}$ , dono diagonals same yellow box mein land karte hain, $s = 2$ . Picture crossing structure clearly dikhata hai: secrets ghar par rahe, phir bhi dono ne ek common value compute ki.

Figure — HTTPS — TLS handshake, certificates, CA

L2.3

Tumhare browser trust store mein root R hai. Ek site bhejti hai: leaf shop.com (intermediate I se signed), aur I (R se signed). Browser do signature checks karti hai, order mein likho.

Recall Solution

shop.com ki signature I ki public key se verify karo (intermediate cert se). ✔ → I shop.com ke liye vouch karta hai.
I ki signature R ki public key se verify karo (trust store se). ✔ → R, I ke liye vouch karta hai, aur R already trusted hai. Trust chain mein transitive hoti hai: leaf → intermediate → root. Root khud isliye trusted hai kyunki woh pre-installed hai, na ki kisi ne use sign kiya hai.

Level 3 — Analysis

(Kisi step ke existence ya uske bina kya toota ka reason socho.)

L3.1

TLS 1.2 handshake mein, client pre-master secret ko server ki public key se encrypt karta hai. Explain karo exactly kaise yeh single act simultaneously (a) ek secret deliver karta hai aur (b) server ko authenticate karta hai.

Recall Solution

(a) Secret deliver karta hai: sirf wahi jo matching private key rakhta hai pre-master secret decrypt kar sakta hai. Toh secret safely pahunch jaata hai — koi eavesdropper use nahi padh sakta.
(b) Authenticate karta hai: kyunki connection tabhi continue hoti hai jab server successfully decrypt kare aur dono sides same keys derive karein, server prove karta hai ki woh woh private key rakhta hai jo certificate mein public key se match hoti hai. Imposter ke paas woh private key nahi → decrypt nahi kar sakta → Finished MAC match nahi karega → handshake fail. Ek message, do kaam. (Note: TLS 1.3 is RSA-transport step ko ECDHE + signature se replace karta hai, precisely forward secrecy paane ke liye.)

L3.2

Finished message mein ek MAC kyun hota hai jo poore handshake transcript par compute hota hai, including earlier cleartext messages?

Recall Solution

Early messages (ClientHello, ServerHello, cipher list) encryption on hone se pehle travel karte hain, toh ek MITM unhe tamper kar sakta hai — jaise strong cipher suites strip karna taaki ek weak suite force ho ("downgrade attack"). Finished MAC abhi tak jo sab kaha gaya uska fingerprint hai, freshly derived session key se keyed. Agar koi bhi earlier byte alter hui, dono sides ke transcripts alag hongey → unke MACs alag hongey → handshake abort ho jaata hai. Yeh negotiation khud ko protect karta hai, sirf baad ka data nahi.

L3.3

Ek recorded TLS session RSA key transport use karti thi (ephemeral DH nahi). Ek saal baad server ki long-term private key leak ho jaati hai. Ek attacker jo puraani ciphertext save karke rakhi thi woh ab kya kar sakta hai — aur ECDHE ne ise kyun rokha hota?

Recall Solution

RSA transport ke saath, pre-master secret server ki long-term public key se encrypt tha. Leaked private key use decrypt karti hai → attacker puraane session keys derive karta hai → poori saved session decrypt ho jaati hai retroactively.
ECDHE ke saath, har session ek throwaway DH key pair use karta tha. DH secrets $a, b$ kabhi store nahi hue aur long-term key se derivable nahi hain. Long-term key leak karna past sessions ke baare mein kuch nahi batata. Yeh property forward secrecy hai, aur isliye TLS 1.3 sirf ECDHE/DHE suites rakhta hai.

Level 4 — Synthesis

(Kai ideas ko ek trace ya design mein combine karo.)

L4.1

https://bank.com/login ke liye ek request ki poori life likho, URL type karne se lekar encrypted data flow tak. Ordered stages aur har ek ka ek kaam list karo.

Recall Solution

DNS lookup — bank.com resolve karo → IP address.
TCP — three-way handshake — SYN, SYN-ACK, ACK port 443 par → reliable byte pipe.
ClientHello — TLS version, random $r_{c}$ , cipher list, SNI = bank.com (Server Name Indication field upar define kiya gaya — yeh server ko batata hai kaunsa certificate present kare).
ServerHello — chosen cipher suite, random $r_{s}$ .
Certificate — server ki cert chain (leaf + intermediates).
Client cert verify karta hai — trusted root tak chain, domain SNI se match kare, expired/revoked nahi.
Key exchange — pre-master secret send hoti hai (RSA-encrypted) ya DH shares exchange hote hain (ECDHE).
Keys derive karo — dono sides PRF (upar define kiya gaya one-way key "blender") chalate hain pre-master secret aur $r_{c}$ aur $r_{s}$ par → identical session keys, locally computed aur kabhi send nahi hoti.
ChangeCipherSpec + Finished — encryption on karo; Finished MAC prove karta hai ki transcript untampered tha.
Encrypted HTTP — ab actual GET /login (ek HTTP request) tunnel ke andar flow karta hai.

L4.2

Design question: ek startup chahta hai "encryption, toh humne ek self-signed certificate banaya." Ek security reviewer ise reject karta hai. Precise failure aur exact attack batao jo yeh enable karta hai.

Recall Solution

Failure: ek self-signed cert ka trusted root tak koi chain nahi hoti. Browser verify nahi kar sakta ki yeh public key sach mein claimed domain ki hai — koi bhi kisi bhi naam ke liye self-signed cert sign kar sakta hai.
Attack enabled (MITM): ek attacker beech mein baithta hai, startup.com ke liye apna self-signed cert present karta hai, aur client ke paas koi tarika nahi hai "legit" self-signed se alag pehchanne ka. Attacker TLS terminate karta hai, sab kuch padh/alter karta hai, aur real server ko re-encrypt karta hai.
Lesson: encryption bina authentication ke hollow hai — tumhare paas shayad attacker tak secure channel hoga. CA-signed cert use karo (jaise Let's Encrypt) taaki chain of trust hold kare.

L4.3

L2.2 ka DH computation repeat karo lekin sirf Bob ka secret $b = 3$ karo (rakho $p = 23$ , $g = 5$ , $a = 6$ ). $B$ aur shared secret $s$ recompute karo, aur confirm karo ki dono sides ab bhi agree karte hain.

Recall Solution

$B = 5^{3} mod 23 = 125 mod 23 = 10$ .
Alice: $s = B^{a} mod p = 1 0^{6} mod 23 = 6$ .
Bob: $s = A^{b} mod p = 8^{3} mod 23 = 512 mod 23 = 6$ . Dono ko $s = 6$ milta hai. Ek secret change karne se poora shared key change ho jaata hai — exactly isliye har session (fresh ephemeral secrets ke saath) ko fresh key milti hai.

Level 5 — Mastery

(Subtle cases, degenerate inputs, aur "exactly kyun.")

L5.1

evil-phishing.com ek perfectly valid Let's Encrypt certificate aur green padlock le leta hai. Kya padlock jhooth bol raha hai? Explain karo ki cert kya prove karta hai aur kya nahi.

Recall Solution

Padlock jhooth nahi bol raha. Ek certificate exactly ek cheez prove karta hai: tum securely address bar mein domain ke real owner se baat kar rahe ho — yahan, evil-phishing.com. Yeh kuch nahi kehta ki woh owner honest hai, safe hai, ya woh hai jo tum sochte ho woh hai. Authenticity ≠ honesty. Jo koi bhi ek domain control kare woh uske liye valid cert le sakta hai. Sahi defence domain name khud check karna hai, sirf padlock nahi.

L5.2

Do extreme DH cases. $p = 23$ , $g = 5$ ke saath: (a) Alice bewakoofi se $a = 0$ pick karti hai. Uski public $A$ kya hai, aur attacker instantly kaunsa shared secret jaanta hai? (b) Maano ek kharab generator ne $A = 1$ diya. Attacker $s$ ke baare mein kya jaanta hai?

Recall Solution

(a) $A = g^{0} mod 23 = 1$ . Tab $s = B^{a} = B^{0} = 1$ kisi bhi Bob ke liye. Attacker $A = 1$ dekhta hai aur instantly jaanta hai "secret" $1$ hai — zero security. Isliye implementations chote/degenerate exponents forbid karti hain.
(b) Agar $A = 1$ , tab $s = A^{b} = 1^{b} = 1$ Bob ke secret se independent. Phir shared secret $1$ par collapse ho jaata hai. Lesson: security is baat par depend karti hai ki $a$ (aur $b$ ) large, random, aur secret hoon. Degenerate inputs jaise $0$ ya values jo $1$ produce karein poori scheme ki discrete-log hardness destroy kar dete hain.

L5.3

Inhe handshake ke dauran unki protection shuru hone ke time ke hisaab se order karo, aur batao agar connection har ek ke theek baad mar jaaye toh abhi bhi kya exposed rahega: (i) ServerHello, (ii) Certificate verified, (iii) Finished exchanged.

Recall Solution

(i) ServerHello ke baad: kuch bhi protect nahi hai. Dono randoms aur cipher choice cleartext mein hain; koi identity confirm nahi, koi keys agree nahi. Sab kuch exposed hai.
(ii) Certificate verified ke baad: client ab jaanta hai server kaun hone ka claim karta hai, lekin keys finalize nahi hue aur encryption on nahi hai. Abhi koi confidential data flow nahi hua — kuch bhi sensitive exposed nahi kyunki kuch bheja hi nahi.
(iii) Finished exchanged ke baad: encryption on hai aur transcript proven untampered hai. Abhi GET /login bhejna safe hai. Agar connection HTTP bhejna shuru karne se pehle mar jaaye, koi bhi application data leak nahi hua. Key insight: TLS deliberately zero sensitive application data Finished se pehle nahi bhejta. Ordering guarantee karta hai ki tum teen saare goals (authenticate, keys agree, transcript verify) meet hone se pehle kabhi leak nahi karte.

Recall Jaane se pehle ek-line self-test

Cover the answers: Encrypted HTTP tak pohochne ka layer order kya hai? ::: DNS → TCP → TLS → HTTP. Valid certificate kya prove karta hai — aur kya nahi? ::: Prove karta hai ki tum real domain owner se baat kar rahe ho; yeh prove nahi karta ki woh honest/safe hain. ECDHE forward secrecy kyun deta hai? ::: Per-session throwaway keys matlab baad mein long-term key leak hone par recorded past traffic decrypt nahi ho sakta.