SSL/TLS कैसे काम करता है: TLS Handshake explained

हर बार जब आप किसी HTTPS website visit करते हैं, तो आपका browser और server एक TLS handshake करते हैं — एक fast exchange जो server को authenticate करता है, encryption parameters पर agree होता है, और एक shared secret key derive करता है। यह किसी भी page content load होने से पहले 1-2 network round trips (50-200ms) में होता है।

TLS 1.3 handshake (current standard)

TLS 1.3 एक ही round trip (1-RTT) में handshake complete करता है:

Step 1 — Client Hello आपका browser भेजता है: supported TLS versions, supported cipher suites, एक random number, और key share parameters (Diffie-Hellman key exchange के लिए)।

Step 2 — Server Hello + Certificate + Finished Server respond करता है: chosen cipher suite, उसका certificate (उसकी identity prove करने के लिए), उसका key share, और एक “Finished” message। TLS 1.3 में, certificate encrypted है — passive observers नहीं देख सकते कि आप किस site से connect हो रहे हैं।

Step 3 — Client Finished Browser अपनी trusted CA list के against certificate verify करता है, Diffie-Hellman exchange से shared session key calculate करता है, और अपना “Finished” message भेजता है। Encrypted application data अब flow हो सकता है।

Total: 1 round trip। Resumed connections (जहाँ client पहले connect हो चुका है) 0-RTT use कर सकते हैं — पहले ही message के साथ encrypted data भेजना।

TLS 1.2 handshake (अभी भी widely used)

TLS 1.2 को 2 round trips चाहिए:

1. Client Hello → supported versions, ciphers, random number
2. Server Hello → chosen cipher, certificate, server key exchange
3. Client Key Exchange → pre-master secret (server की public key से encrypted या Diffie-Hellman के through)
4. Change Cipher Spec + Finished (दोनों sides)

TLS 1.2 ज़्यादा cipher suites support करता है — कुछ weak भी। TLS 1.3 की तुलना में proper configuration ज़्यादा matter करता है।

Encrypted connection के अंदर क्या होता है

Handshake के बाद, सारा data negotiated session key use करके एक symmetric cipher (आमतौर पर AES-256-GCM या ChaCha20-Poly1305) से encrypt किया जाता है:

• Confidentiality — Data encrypted है; सिर्फ दो endpoints इसे read कर सकते हैं
• Integrity — हर message में MAC (message authentication code) included है; किसी भी tampering का पता चलता है
• Authentication — Server का certificate उसकी identity prove करता है (और optionally, client की)

हर HTTP request और response — headers, body, cookies, URLs — इस encrypted channel से गुज़रते हैं।

Forward secrecy

Modern TLS ephemeral Diffie-Hellman key exchange use करता है, जिसका मतलब है कि हर connection एक unique session key generate करता है। भले ही बाद में server की private key compromise हो, past conversations को decrypt नहीं किया जा सकता।

TLS 1.3 forward secrecy को mandatory बनाता है। TLS 1.2 इसे support करता है लेकिन RSA key exchange की भी permission देता है (जो forward secrecy provide नहीं करता)। इसीलिए TLS 1.3 preferred है।

Certificate की role

TLS handshake server के पास valid SSL/TLS certificate होने पर depend करता है। Certificate provide करता है:

1. Server की public key — key exchange के दौरान use होती है
2. Domain name — browser check करता है कि ये URL से match करते हैं
3. CA signature — prove करता है कि एक trusted Certificate Authority ने इस certificate को validate किया है
4. Validity dates — browser expired certificates reject करता है

Valid certificate के बिना, handshake fail हो जाता है और browser security warning show करता है। Free certificate लें →

Performance

Modern hardware पर, encryption की CPU cost negligible है — AES-NI instructions इसे hardware में handle करते हैं। Main cost extra round trips है, जिसे TLS 1.3 minimize करता है।

Wire पर आप क्या देख सकते हैं

HTTPS के बिना (HTTP)

Network पर एक observer सब कुछ देखता है:

GET /login HTTP/1.1
Host: example.com
Cookie: session=abc123

username=admin&password=secret123

Username, password, cookies, page content — सब plaintext में।

HTTPS के साथ (TLS)

Same observer देखता है:

[TLS handshake — server certificate visible in TLS 1.2, encrypted in TLS 1.3]
[Encrypted application data — indistinguishable from random bytes]
[Encrypted application data]
[Encrypted application data]

वे destination IP address और SNI hostname (TLS 1.2 में — TLS 1.3 में ECH के साथ encrypted) देख सकते हैं। वे URL path, headers, body, या cookies नहीं देख सकते।

Certificate कैसे fit होता है

TLS handshake server के पास valid SSL/TLS certificate होने पर depend करता है:

1. Server की public key — key exchange के दौरान use होती है
2. Domain name — browser check करता है कि ये URL से match करते हैं
3. CA signature — prove करता है कि एक trusted Certificate Authority ने इस certificate को validate किया है
4. Validity dates — browser expired certificates reject करता है

Valid certificate के बिना, handshake fail हो जाता है और browser security warning show करता है। Free certificate लें →

2026 में common TLS cipher suites

TLS 1.3 (सिर्फ 5 cipher suites — सभी secure)

TLS_AES_256_GCM_SHA384       ← सबसे common
TLS_AES_128_GCM_SHA256       ← widely used
TLS_CHACHA20_POLY1305_SHA256 ← mobile/ARM के लिए best
TLS_AES_128_CCM_SHA256       ← IoT/embedded
TLS_AES_128_CCM_8_SHA256     ← IoT/embedded (short tag)

TLS 1.2 (सिर्फ AEAD suites use करें)

ECDHE-ECDSA-AES256-GCM-SHA384  ← ECC cert के साथ best
ECDHE-RSA-AES256-GCM-SHA384    ← RSA cert के साथ best
ECDHE-ECDSA-CHACHA20-POLY1305  ← mobile-optimized

TLS 1.2 में non-AEAD suites (CBC mode) से बचें — वे BEAST और Lucky13 जैसे attacks के लिए vulnerable रहे हैं।

FAQ

क्या HTTPS मेरी website को slow करता है?

TLS handshake first connection पर एक round trip (TLS 1.3) या दो (TLS 1.2) add करता है। Session resumption returning visitors के लिए इसे eliminate करता है। चूँकि HTTPS HTTP/2 (multiplexing, header compression) enable करता है, HTTPS sites overall अक्सर faster होती हैं।

Cipher suite क्या है?

Cipher suite key exchange, encryption, और message authentication के लिए use किए जाने वाले algorithms का combination है। Example: TLS_AES_256_GCM_SHA384 का मतलब है AES-256-GCM encryption और message integrity के लिए SHA-384 के साथ TLS। TLS 1.3 में सिर्फ 5 cipher suites हैं — सभी secure। TLS 1.2 में 37 हैं, जिनमें से कुछ weak हैं।

क्या कोई बाद में HTTPS traffic decrypt कर सकता है?

Forward secrecy (ephemeral key exchange) के साथ नहीं। हर session Diffie-Hellman exchange से derived एक unique key use करता है। भले ही server की long-term private key compromise हो, past session keys recover नहीं की जा सकतीं। TLS 1.3 इसे enforce करता है; TLS 1.2 correctly configured होने पर इसे support करता है।

GetHTTPS इससे कैसे related है?

GetHTTPS वह certificate generate करता है जो TLS handshake को possible बनाता है। Certificate में public key होती है जिसे server key exchange के दौरान use करता है। GetHTTPS Web Crypto API use करके आपके browser में यह key pair create करता है और इसे sign कराने के लिए directly Let’s Encrypt के ACME API से connect होता है। GetHTTPS कैसे काम करता है →