Forward Secrecy (Perfect Forward Secrecy) क्या है?

Forward secrecy (जिसे Perfect Forward Secrecy / PFS भी कहा जाता है) TLS connection की एक property है जो guarantee देती है: भले ही future में server की private key compromise हो जाए, past encrypted communication को decrypt नहीं किया जा सकता।

यह हर connection के लिए एक unique, ephemeral (temporary) key generate करके काम करता है। Connection end होने के बाद, ephemeral key discard कर दी जाती है। कोई भी — server owner भी नहीं — इसे recreate कर सकता है।

Forward secrecy क्यों matter करती है

Forward secrecy के बिना (RSA key exchange)

Attacker records encrypted traffic today
     ↓
Years later, attacker steals server's RSA private key
     ↓
Attacker decrypts ALL recorded traffic — passwords, messages, everything

Static RSA key exchange (ECDHE के बिना TLS 1.2) के साथ, हर session को decrypt करने के लिए एक ही server private key use की जाती है। अगर वह key कभी चोरी हो जाए, तो हर past conversation expose हो जाती है।

Forward secrecy के साथ (ECDHE key exchange)

Attacker records encrypted traffic today
     ↓
Years later, attacker steals server's private key
     ↓
Can't decrypt past traffic — each session used a unique ephemeral key
that was discarded after the session ended

हर connection एक नया Diffie-Hellman key pair generate करता है, एक unique session key calculate करता है, और complete होने पर ephemeral key destroy कर देता है। Server की long-term private key सिर्फ authentication (identity prove करने) के लिए use की जाती है, key exchange (encryption key derive करने) के लिए नहीं।

यह technically कैसे काम करता है

1. Client और server दोनों एक ephemeral ECDHE key pair generate करते हैं (random, per-connection)
2. वे इन ephemeral keys के public parts exchange करते हैं
3. दोनों एक same shared secret calculate करते हैं अपनी private ephemeral key + दूसरे की public ephemeral key use करके (यह Diffie-Hellman math है)
4. Shared secret से session key derive होती है जो AES encryption के लिए use होती है
5. Session key derive होने के बाद ephemeral keys discard कर दी जाती हैं

Server के certificate की private key सिर्फ handshake messages पर sign करने के लिए use की जाती है — यह prove करने के लिए कि server genuine है। इसका use कभी traffic decrypt करने के लिए नहीं किया जाता।

TLS versions में forward secrecy

TLS 1.3 ने RSA key exchange remove करके इसे solve किया — सभी TLS 1.3 connections में default रूप से forward secrecy है। कोई configuration ज़रूरी नहीं।

कैसे check करें कि आपके server में forward secrecy है

# Check which key exchange your server uses
echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | grep -E "Server Temp Key|Protocol"

देखें:

• Server Temp Key: ECDH, P-256 → Forward secrecy (ECDHE)
• Server Temp Key: X25519 → Forward secrecy
• कोई Server Temp Key line नहीं → RSA key exchange, forward secrecy नहीं

TLS 1.2 में forward secrecy ensure करें

Nginx:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
ssl_prefer_server_ciphers off;

सभी cipher suites ECDHE से start होते हैं — ephemeral key exchange।

Apache:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder off

Real-world relevance

Forward secrecy इनसे protect करती है:

• State-level surveillance — Governments अभी encrypted traffic record कर रही हैं, उम्मीद करते हुए कि बाद में keys मिलने पर (legal orders, hacking, या quantum computing के through) decrypt करेंगे
• Server compromise — अगर कोई attacker आपके server की private key चुराता है, तो वह सिर्फ आगे server impersonate कर सकता है, past traffic decrypt नहीं कर सकता
• Key leak — Private keys का accidental exposure (जैसे, Git में commit, backups में include)

इसीलिए Let’s Encrypt ECDSA certificates recommend करता है — वे complete elliptic-curve-based handshake के लिए ECDHE key exchange के साथ naturally pair होते हैं।

FAQ

क्या मेरे SSL certificate को forward secrecy support करना चाहिए?

Certificate खुद forward secrecy determine नहीं करता — cipher suite करता है। कोई भी certificate (RSA या ECDSA) ECDHE key exchange के साथ काम करता है। लेकिन ECDSA certificates ECDHE के साथ ज़्यादा naturally pair होते हैं (दोनों elliptic curves use करते हैं), जिसके result में faster handshake होता है।

क्या forward secrecy default रूप से enabled है?

TLS 1.3 में: हमेशा — यह mandatory है। TLS 1.2 में: आपके server config पर depend करता है। Modern defaults (Nginx, Apache) ECDHE cipher suites को prefer करते हैं, लेकिन पुराने configs अभी भी RSA key exchange allow कर सकते हैं।

क्या forward secrecy चीज़ों को slow करती है?

Negligible। ECDHE key exchange modern hardware पर handshake में ~1ms add करता है। Security benefit cost से कहीं ज़्यादा है।

TLS 1.3 में 0-RTT mode के बारे में क्या?

0-RTT (zero round trip resumption) एक special case है। 0-RTT में भेजा गया early data server compromise के against forward secrecy नहीं रखता (resumption के लिए use किया जाने वाला PSK previous session की keys से derive होता है)। इसीलिए 0-RTT सिर्फ safe, idempotent requests के लिए use किया जाना चाहिए।