Question bank — HTTPS — TLS handshake, certificates, CA

False. Yeh sirf itna guarantee karta hai ki tum securely us domain ke asli owner se baat kar rahe ho; ek phishing site bhi perfectly valid certificate hold kar sakti hai. Authenticity honesty nahi hoti.

False. Path aur query encrypt hote hain, lekin hostname cleartext mein SNI ke zariye jaata hai taaki server jaane ki kaun sa certificate bhejna hai. Sirf recent ECH/ESNI use karne se yeh bhi chupta hai.

False. Cryptography (AES, RSA/ECDHE) bilkul identical hoti hai; self-signed cert mein bas chain of trust nahi hoti jo root tak jaaye, isliye browser identity verify nahi kar sakta.

False. Certificate mein server ki public key hoti hai authentication aur key-bootstrap ke liye. Bulk symmetric key har session mein fresh derive hoti hai aur kabhi transmit nahi ki jaati.

False. HTTPS literally TLS tunnel ke andar HTTP hai — same GET/POST methods aur status codes encrypted form mein chalta rehta hai. Dekho HTTP — methods, status codes.

False. TLS ko ek reliable byte stream chahiye, isliye TCP — three-way handshake (SYN, SYN-ACK, ACK) pehle complete hota hai; uske baad TLS handshake uske upar shuru hoti hai.

False. Secret $s=g^{ab}\mathrm{mod}p$ kabhi nahi bheji jaati; har side ise independently apni private value aur doosre ki public value se compute karta hai.

False (with ECDHE). Ephemeral Diffie–Hellman har session ke baad apna key pair phek deta hai, jisse forward secrecy milti hai. Yeh sach hai sirf purane RSA key transport ke liye, jahaan leaked key recorded pre-master secrets ko decrypt kar deti hai.

False. Finished ek MAC hai poore handshake transcript ke upar; yeh prove karta hai ki kisi ne pehle ke cleartext negotiation messages ke saath tamper nahi kiya. Ise drop karna algorithm negotiation ko attackable chhod deta.

False for domain-validated certs. Ek basic CA sirf yeh check karta hai ki tum domain control karte ho. Organisation ki vetting ek alag, mehenga tier hai (OV/EV).

Asymmetric sirf bootstrap aur sign karne ke liye use hoti hai — yeh bulk data ke liye bahut slow hai. Fast symmetric key sab page bytes handle karta hai. Yeh hybrid split hi Symmetric vs Asymmetric Encryption ka poora point hai.

Browser ek root CA ko trust karta hai jo uske trust store mein baka hua hai, bank.com ko nahi. Trust transitively flow karta hai: root → intermediate → leaf, har link ek verified signature hai. Dekho Public Key Infrastructure (PKI).

Tum verify karte ho signer ki public key se; sirf signer ke paas private key hoti hai. Inhe mix karna Digital Signatures & Hashing ke poore security model ko ulta kar deta hai.

Woh public hain, lekin har side ek contribute karta hai, isliye koi bhi akela party derived key control nahi kar sakta, aur pair har session ki keys ko unique banata hai — purani handshake ka replay defeat karta hai.

RSA key transport mein sirf client ise generate karta hai, phir server ki public key se encrypt karta hai. Sirf master secret dono PRF ke zariye compute karte hain.

Mushkil problem hai discrete logarithm: $g^a\mathrm{mod}p$ se $a$ recover karna. Factoring RSA ki problem hai, ek alag assumption. Dekho Diffie–Hellman Key Exchange.

Ek expired cert validity check tod deta hai, isliye browser ise trust nahi kar sakta. Expiry us window ko limit karti hai jisme ek key quietly compromise ho sakti hai, isliye yeh ek hard failure hai, cosmetic nahi.

TLS 1.3 phir bhi certificate aur Finished bhejta hai; woh sirf pipeline karta hai key share ko ClientHello mein ek round trip bachane ke liye. Authentication intact rehta hai.

Woh $g^a$ aur $g^b$ dekhte hain lekin unhe $g^{ab}$ chahiye; wahan pahunchne ke liye $a$ ya $b$ recover karne ke liye discrete log solve karna padega, jo computationally infeasible maana jaata hai.

Taaki koi bhi side predictable key force na kar sake. Agar sirf ek ne randomness contribute ki hoti, toh ek compromised ya malicious peer key ko weak ya known value ki taraf steer kar sakta tha.

DH secret ko passive watchers se chhupaata hai lekin ek MITM do DH exchanges chala ke beech mein baith sakta hai. Certificate authenticate karta hai ki kiske public value ke saath tum combine kar rahe ho, MITM ko khatam karta hai.

Root keys trust ka anchor hain; inhe network par fetch karna khud kisi already-trusted cheez par depend karta. Inhe bake in karna (ek out-of-band, vendor-vetted step) poori chain ko bootstrap karta hai.

attacker.com ke liye validly signed cert real hai — lekin ise bank.com authenticate nahi karna chahiye. Requested host ko cert ke naam se match karna ek valid cert ko wrong site ke liye reuse hone se rokta hai.

PRF one-way hai aur ek secret ko is session ke nonces se bound kai independent keys mein stretch karta hai (encryption, MAC, dono directions), taaki ek derived key ka leak doosri keys reveal na kare.

DNS sirf ek naam ko IP address pe map karta hai; yeh prove nahi karta ki us IP par machine genuine hai. Yeh proof TLS ka kaam hai certificate ke zariye.

Browser ise reject karta hai (name-mismatch error). example.net ka cert example.com ko authenticate nahi kar sakta, chahe perfectly signed ho.

Handshake fail ho jaati hai bina kisi agreed suite ke; ServerHello ek choose nahi kar sakta, isliye koi secure channel nahi banta aur connection abort ho jaata hai.

Verification break ho sakti hai kyunki browser leaf ko trusted root se bridge nahi kar sakta. Kuch browsers missing intermediate fetch karte hain, lekin ek sahi server ko full chain bhejna chahiye.

0-RTT mein early data replayable hota hai — ek attacker ise dobara bhej sakta hai — isliye yeh sirf idempotent, non-state-changing requests carry kar sakta hai.

Nahi. Sirf HTTPS transfer encrypted aur integrity-checked hai; HTTP wala cleartext mein cookies leak karta hai, isliye "Secure" cookies plain HTTP par travel karne se refuse karti hain.

Ek attacker kisi bhi domain ke liye certs forge kar sakta hai, isliye us root ko revoke/distrust karke trust stores se remove karna padega — ek catastrophic, industry-wide event, isliye roots offline guard kiye jaate hain.