4.3.27 · Coding › Computer Networks
Intuition Ek-sentence mein picture
HTTPS basically HTTP hai jo ek encrypted, authenticated tunnel ke andar run karta hai — aur yeh tunnel TLS banata hai.
Koi bhi web data flow karne se pehle, dono sides ek handshake karte hain jo teen kaam karta hai:
server ko authenticate karna (CA ke signed certificate ke through), keys pe agree karna (key exchange ke through),
aur encryption on karna. Uske baad, normal HTTP bytes safely andar se guzarte hain.
Plain HTTP mein sab kuch TCP ke upar cleartext mein jaata hai. Path mein koi bhi (tumhara café Wi-Fi, tumhara ISP, koi router) yeh kar sakta hai:
Tumhare passwords/cookies padh sakta hai (koi confidentiality nahi),
Page ko modify kar sakta hai (ads/malware inject karo → koi integrity nahi),
Server ki impersonation kar sakta hai (tumhare bank ka natak karo → koi authenticity nahi).
HTTPS = HTTP + TLS (Transport Layer Security), typically port 443 pe. TLS teen guarantees deta hai:
Confidentiality — eavesdroppers sirf ciphertext dekhte hain.
Integrity — tampering detect ho jaata hai (MAC / AEAD tag ke through).
Authentication — tum sach mein claimed server se baat kar rahe ho (certificates ke through).
Definition Crypto primitives jo use hote hain
Symmetric cipher (e.g. AES-GCM): ek shared key, fast, bulk data ke liye use hota hai.
Asymmetric/public-key (RSA, ECDSA, ECDHE): ek key pair (public + private). Sirf symmetric key bootstrap karne aur sign karne ke liye use hota hai.
Hash (SHA-256): one-way fingerprint.
Digital signature : signer data ko hash karta hai, hash ko apni private key se encrypt karta hai; koi bhi public key se verify kar sakta hai.
DO tarah ka crypto kyun? Asymmetric identity ke liye secure hai but slow hai. Symmetric fast hai but usse shared secret chahiye. Toh hum asymmetric ek baar use karte hain symmetric key safely set up karne ke liye, phir baaki sab ke liye symmetric. Yahi TLS ke dil mein hybrid idea hai.
Akela key exchange bekar hai agar ek attacker middle mein baith ke (MITM) tumhe apni public key de de. Hume proof chahiye ki public key bank.com ki hai.
Definition Certificate & CA
Ek certificate ek signed document hai jo ek domain name ko ek public key se bind karta hai, saath mein validity dates aur issuer info. Ise ek Certificate Authority (CA) sign karta hai — ek trusted third party (e.g. Let's Encrypt, DigiCert).
Tumhara OS/browser CA root public keys ka ek trust store lekar aata hai. Ek certificate trusted hai agar woh ek valid chain of trust banaata hai: leaf → intermediate(s) → root, har ek agले ne sign kiya, jo ek aisi root pe khatam ho jo tumhara browser pehle se trust karta hai.
Intuition Chain kyun kaam karta hai
Tum bank.com ko directly trust nahi karte. But tum root CA ki public key trust karte ho (jo tumhare browser mein baked hai). Root ek intermediate ko vouch karta hai, jo bank.com ko vouch karta hai. Trust signatures ke through transitive hai: har link ka signature next-up public key se verify hota hai.
Hum ise teen goals se build karte hain, puchte hue "yeh message kyun chahiye?"
Worked example TLS 1.2 (RSA-style) handshake, message by message
1. ClientHello → client bhejta hai: TLS version, ek random nonce r c , cipher suites ki list, supported extensions (SNI = kaun sa hostname).
Yeh step kyun? Dono sides ko parameters pe agree karna hai; random nonce key derivation mein jaata hai taaki keys har session mein alag hon (replay attacks defeat hote hain).
2. ServerHello → server ek cipher suite pick karta hai + apna random nonce r s bhejta hai.
Kyun? Shared algorithms lock in karne ke liye aur server ki randomness contribute karne ke liye.
3. Certificate → server apna cert chain (leaf + intermediates) bhejta hai.
Kyun? Taaki client server ko authenticate kar sake aur trusted public key extract kar sake.
4. (Client cert verify karta hai) : chain ke upar signatures check karta hai ek trusted root tak, domain SNI se match check karta hai, expiry/revocation check karta hai.
Kyun? MITM ko fake public key substitute karne se rokta hai.
5. Key exchange : client ek pre-master secret generate karta hai, ise server ki public key se encrypt karta hai, bhejta hai.
Kyun? Sirf matching private key ka holder ise decrypt kar sakta hai → prove karta hai server genuine hai aur ek shared secret deliver karta hai.
6. Dono keys derive karte hain : master = PRF ( pre-master , r c , r s ) , phir master se session keys.
Kyun? Dono randoms mix karne se matlab hai ki koi bhi side akele key control nahi karti; keys har session mein unique hain.
7. ChangeCipherSpec + Finished (dono sides): "ab se, encrypted"; Finished = poore transcript ka MAC.
Kyun? Finished MAC prove karta hai ki kisine pehle ke (unencrypted) handshake messages alter nahi kiye — negotiation ko khud protect karta hai.
Intuition Forward secrecy (kyun TLS 1.3 ECDHE prefer karta hai)
Plain RSA key transport mein, agar server ki private key baad mein leak ho jaaye, toh ek attacker jo purana traffic record kar chuka hai use decrypt kar sakta hai (woh purana pre-master decrypt karta hai). Ephemeral Diffie–Hellman (ECDHE) ke saath, har session ek throwaway DH key pair use karta hai, isliye past sessions safe rehte hain chahe long-term key leak ho jaaye. Yeh property forward secrecy hai.
TLS 1.3 ise streamline karta hai: ClientHello already ek DH key share include karta hai; server apna share + cert + Finished reply karta hai. Data 1 round trip ke baad flow kar sakta hai (ya resumption ke liye 0-RTT). Sirf forward-secret ECDHE/DHE suites rehte hain.
Common mistake "HTTPS URL/domain ko completely encrypt karta hai."
Kyun sahi lagta hai: page content encrypted hai, toh surely sab kuch hoga. Fix: path/query encrypted hain, but domain (SNI) classic TLS mein cleartext mein bheja jaata hai taaki server jaane kaun sa cert present karna hai. ESNI/ECH sirf recently isko fix karta hai.
Common mistake "Certificate hi encryption key hai."
Kyun sahi lagta hai: certs security ke baare mein hain aur ek key contain karte hain. Fix: cert server ki public key authentication/key-bootstrap ke liye hold karta hai, symmetric session key nahi. Bulk traffic derived symmetric key use karta hai, kabhi cert nahi.
Common mistake "Ek valid certificate matlab site safe/honest hai."
Kyun sahi lagta hai: padlock trustworthy lagta hai. Fix: ek cert sirf prove karta hai ki tum us domain ke real owner se securely baat kar rahe ho. evil-phishing.com ek perfectly valid Let's Encrypt cert le sakti hai. Authenticity ≠ honesty.
Common mistake "Self-signed certs utne hi achhe hain."
Kyun sahi lagta hai: same crypto, same encryption strength. Fix: koi chain to trusted root nahi hai, isliye browser identity verify nahi kar sakta — ek MITM bhi self-sign kar sakta hai. Authentication ke bina encryption hollow hai.
Recall Feynman: ek 12-saal ke bachche ko samjhao
Socho tum ek shopkeeper ko koi secret whisper karna chahte ho, but tumse kabhi nahi mili aur gali pickpocketers se bhari hai.
Pehle tum unka ID card maangoge jo town mayor ne stamp kiya ho jis pe tum already trust karte ho — yeh prove karta hai woh asli shopkeeper hain, koi imposter nahi (certificate + CA).
Phir tum dono ek shared secret password ek clever tarike se invent karte ho taaki watchers bhi nahi figure out kar sakein (key exchange / Diffie–Hellman).
Tab se tum ek code mein baat karte ho jo sirf tum dono jaante ho (symmetric encryption). Pickpockets ko gibberish dikhta hai. Pura yeh "ID dikhao, secret code pe agree karo" greeting hi handshake hai.
"Cool Servers Carry Keys, Change, Finish" → C lientHello, S erverHello, C ertificate, K ey exchange, C hangeCipherSpec, F inished.
HTTPS kaun se do protocols se bana hai aur kaun se port pe? HTTP + TLS, port 443.
TLS kaun si teen security guarantees deta hai? Confidentiality, integrity, authentication.
Domain name ko public key se kaun bind karta hai aur use kaun sign karta hai? Ek certificate; Certificate Authority (CA) sign karta hai.
Chain of trust kya hai? Leaf cert → intermediate(s) → root, har ek agale ne sign kiya, browser ke trust store mein ek root pe khatam hota hai.
TLS mein asymmetric aur symmetric crypto dono kyun use hote hain (hybrid)? Asymmetric securely ek shared secret bootstrap karta hai (slow), phir fast symmetric crypto bulk data encrypt karta hai.
RSA key transport mein client server ki public key se kya encrypt karta hai? Pre-master secret.
Master secret kis se derive hota hai? PRF(pre-master secret, client random, server random).
Forward secrecy kya hai aur kaun sa exchange ise deta hai? Past sessions safe rehte hain chahe long-term key baad mein leak ho jaaye; ephemeral Diffie–Hellman (ECDHE) se milta hai.
Finished message kya protect karta hai? Poore handshake transcript ki integrity (earlier cleartext messages ke saath tampering detect karta hai).
Self-signed cert browsers ko kyun untrusted lagta hai? Trusted root CA tak koi chain nahi, isliye identity verify nahi ho sakti.
Kya valid cert matlab site honest hai? Nahi — yeh sirf prove karta hai ki tum securely real domain owner se baat kar rahe ho; phishing sites ke paas bhi valid certs ho sakte hain.
Diffie–Hellman ko secure kaun si hard problem banati hai? Discrete logarithm problem (g a mod p se a recover karna).
Full TLS 1.3 handshake mein kitne round trips hote hain? 1 RTT (resumption ke liye 0-RTT).
HTTPS ke saath bhi (classic TLS mein) URL ka kaun sa part visible rehta hai? SNI ke through domain name; path/query encrypted hote hain.
HTTP — methods, status codes
TCP — three-way handshake (TLS ek established TCP connection ke upar ride karta hai)
Symmetric vs Asymmetric Encryption
Diffie–Hellman Key Exchange
Digital Signatures & Hashing
Public Key Infrastructure (PKI)
DNS (us domain ko resolve karta hai jiska cert tum phir verify karte ho)
Confidentiality Integrity Authentication
Certificate binds domain to public key
Chain of trust leaf to root