#Forward Secrecy (Perfect Forward Secrecy)

Step 1: Client Hello

plaintext🌐 Browser → 🏦 Server

ClientHello:
  - TLS Version: 1.3
  - Supported Cipher Suites:
      • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ← Uses ECDHE (Forward Secrecy!)
      • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ← Uses ECDHE (Forward Secrecy!)
  - Supported Curves: X25519, secp256r1
  - Client Random: [random bytes]

Step 2: Server Response

plaintext🏦 Server → 🌐 Browser

ServerHello:
  - Selected Cipher: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  - Server Random: [random bytes]

Certificate:
  - Server's certificate with long-term RSA/ECDSA public key
  - Used ONLY for authentication, NOT encryption!

Server Key Exchange:
  - Ephemeral Public Key: [temporary DH public key] ← THIS IS THE KEY!
  - Signature: [signed with server's long-term private key]

  The ephemeral key is:
    ✅ Generated fresh for THIS session only
    ✅ Will be deleted immediately after session ends
    ✅ Cannot be derived from server's long-term private key

Step 3: Client Key Exchange

plaintext🌐 Browser → 🏦 Server

Client Key Exchange:
  - Client's Ephemeral Public Key: [temporary DH public key]

Now both sides can compute the same shared secret:
  Server: shared_secret = DH(server_ephemeral_private, client_ephemeral_public)
  Client: shared_secret = DH(client_ephemeral_private, server_ephemeral_public)

  Result: BOTH get the SAME secret, but it was never transmitted!

Step 4: Session Keys Derived

plaintextBoth Browser and Server independently compute:

Session Keys = KDF(shared_secret, client_random, server_random)

Generated keys:
  ✅ Client Write Key (for encrypting client→server traffic)
  ✅ Server Write Key (for encrypting server→client traffic)
  ✅ Client MAC Key (for message authentication)
  ✅ Server MAC Key (for message authentication)

🗑️  Ephemeral private keys are IMMEDIATELY DELETED after deriving session keys!

Step 5: Secure Communication

plaintext🔒 Encrypted HTTPS traffic flows using session keys

After session ends:
  🗑️  Session keys are deleted
  🗑️  Ephemeral private keys are already deleted
  ❓ Attacker who steals server's long-term key cannot:
      ❌ Recreate the ephemeral keys (they're gone forever)
      ❌ Derive the shared secret (requires ephemeral private keys)
      ❌ Decrypt this session's traffic

✅ Forward Secrecy achieved!

Step 1: Client Hello

plaintext🌐 Browser → 🏦 Server

ClientHello:
  - Cipher Suites:
      • TLS_RSA_WITH_AES_256_CBC_SHA ← Plain RSA (NO Forward Secrecy!)

Step 2: Server Sends Certificate

plaintext🏦 Server → 🌐 Browser

ServerHello + Certificate:
  - Server's certificate with RSA public key
  - This key will be used for BOTH authentication AND encryption

Step 3: Client Encrypts Pre-Master Secret

plaintext🌐 Browser generates pre-master secret

Pre-Master Secret: [random 48 bytes]

Encrypts it with server's RSA public key:
  Encrypted Pre-Master = RSA_Encrypt(server_public_key, pre_master_secret)

🌐 Browser → 🏦 Server: [Encrypted Pre-Master Secret]

plaintext✅ EXCELLENT (TLS 1.3 - Forward Secrecy by default):
  - TLS_AES_256_GCM_SHA384
  - TLS_AES_128_GCM_SHA256
  - TLS_CHACHA20_POLY1305_SHA256

  Note: TLS 1.3 ALWAYS uses ephemeral keys!

✅ GOOD (TLS 1.2 with ECDHE):
  - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

✅ ACCEPTABLE (TLS 1.2 with DHE - slower but still secure):
  - TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  - TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

Key Indicators:

• ECDHE = Elliptic Curve Diffie-Hellman Ephemeral ← BEST (fast, strong)
• DHE = Diffie-Hellman Ephemeral ← GOOD (slower, but compatible)
• TLS 1.3 ciphers = ALWAYS have Forward Secrecy built-in

plaintext❌ NO FORWARD SECRECY (RSA Key Exchange):
  - TLS_RSA_WITH_AES_256_CBC_SHA256
  - TLS_RSA_WITH_AES_128_CBC_SHA
  - TLS_RSA_WITH_AES_256_GCM_SHA384
  - TLS_RSA_WITH_3DES_EDE_CBC_SHA

❌ DEPRECATED AND INSECURE:
  - TLS_RSA_WITH_RC4_128_SHA (RC4 broken)
  - TLS_RSA_WITH_DES_CBC_SHA (DES broken)
  - SSL_RSA_WITH_* (all SSL versions broken)

Danger Signs:

• RSA in key exchange position (e.g., TLS_RSA_WITH_...)
• No DHE or ECDHE in the name
• Legacy SSL ciphers

nginx# Optimal TLS configuration with Forward Secrecy
server {
    listen 443 ssl http2;
    server_name example.com;

    # Certificate configuration
    ssl_certificate /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    # Protocol versions - TLS 1.2 and 1.3 only
    ssl_protocols TLSv1.2 TLSv1.3;

    # Cipher suites - ONLY Forward Secrecy enabled ciphers
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';

    # Prefer server cipher order
    ssl_prefer_server_ciphers on;

    # DH parameters for DHE ciphers (if using DHE)
    ssl_dhparam /etc/ssl/certs/dhparam.pem;

    # Enable session resumption (doesn't break Forward Secrecy)
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_session_tickets off;  # Disable tickets to maintain PFS

    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;

    # Security headers
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    location / {
        root /var/www/html;
        index index.html;
    }
}

bash# Generate strong DH parameters (takes several minutes)
openssl dhparam -out /etc/ssl/certs/dhparam.pem 4096

# Or use 2048-bit (faster generation, still secure)
openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

Why this matters:

• Default DH parameters are often weak (1024-bit or shared)
• Custom strong DH parameters prevent attacks on DHE ciphers
• 2048-bit is minimum recommended, 4096-bit is better

apache<VirtualHost *:443>
    ServerName example.com
    DocumentRoot /var/www/html

    # Certificate configuration
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/example.com.crt
    SSLCertificateKeyFile /etc/ssl/private/example.com.key
    SSLCertificateChainFile /etc/ssl/certs/intermediate.crt

    # Protocol versions - TLS 1.2 and 1.3 only
    SSLProtocol -all +TLSv1.2 +TLSv1.3

    # Cipher suites - ONLY Forward Secrecy enabled
    SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256

    # Prefer server cipher order
    SSLHonorCipherOrder on

    # Use strong DH parameters
    SSLOpenSSLConfCmd DHParameters "/etc/ssl/certs/dhparam.pem"

    # Session settings
    SSLSessionCache "shmcb:/var/run/ssl_scache(512000)"
    SSLSessionTickets off

    # OCSP Stapling
    SSLUseStapling on
    SSLStaplingCache "shmcb:/var/run/ocsp(128000)"

    # Security headers
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</VirtualHost>

bash# Test Forward Secrecy with OpenSSL
openssl s_client -connect example.com:443 -cipher ECDHE

# Check which cipher suite was negotiated
openssl s_client -connect example.com:443 2>&1 | grep "Cipher"

# Expected output (Forward Secrecy enabled):
# Cipher    : ECDHE-RSA-AES256-GCM-SHA384

# Test that RSA ciphers are NOT available
openssl s_client -connect example.com:443 -cipher RSA

# Expected output (should FAIL if PFS is properly configured):
# error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small

Interpreting Results:

plaintext✅ GOOD - Forward Secrecy Working:
   Cipher: ECDHE-RSA-AES256-GCM-SHA384
   Cipher: ECDHE-ECDSA-CHACHA20-POLY1305
   Cipher: DHE-RSA-AES256-GCM-SHA384

❌ BAD - NO Forward Secrecy:
   Cipher: AES256-SHA
   Cipher: DES-CBC3-SHA
   Cipher: RSA-AES256-GCM-SHA384

SSL Labs Server Test (https://www.ssllabs.com/ssltest/)

plaintextTest your server and look for:

✅ GOOD INDICATORS:
  - Forward Secrecy: Yes (with modern clients)
  - TLS 1.3 support: Yes
  - Top cipher suite uses ECDHE

❌ WARNING SIGNS:
  - Forward Secrecy: No
  - RSA key exchange available
  - Old TLS versions enabled (TLS 1.0, TLS 1.1)

What SSL Labs Shows:

bash#!/bin/bash
# Test Forward Secrecy for a domain

DOMAIN=$1

echo "Testing Forward Secrecy for: $DOMAIN"
echo "=========================================="

# Test ECDHE support
echo -n "ECDHE Support: "
if openssl s_client -connect "$DOMAIN:443" -cipher ECDHE 2>&1 | grep -q "Cipher is ECDHE"; then
    echo "✅ SUPPORTED"
else
    echo "❌ NOT SUPPORTED"
fi

# Test that RSA is disabled
echo -n "RSA Key Exchange Disabled: "
if openssl s_client -connect "$DOMAIN:443" -cipher RSA 2>&1 | grep -q "Cipher is"; then
    echo "❌ ENABLED (BAD - no Forward Secrecy)"
else
    echo "✅ DISABLED (GOOD)"
fi

# Get actual cipher negotiated
echo "Negotiated Cipher:"
openssl s_client -connect "$DOMAIN:443" 2>&1 < /dev/null | grep "Cipher" | head -1

# Check TLS version
echo "TLS Version:"
openssl s_client -connect "$DOMAIN:443" 2>&1 < /dev/null | grep "Protocol" | head -1

Usage:

bashchmod +x test-pfs.sh
./test-pfs.sh example.com