Security Protocols — Encryption, Authentication and Secure Communication

Category: Security Protocols — These protocols provide encryption, authentication, integrity, and secure communication over potentially untrusted networks like the internet. They protect data confidentiality, verify identities, and prevent tampering.

Table of Contents

1. SSL
2. SSH
3. HTTPS
4. IPSEC
5. TLS

1. SSL (Secure Sockets Layer)

What is SSL?

SSL is a cryptographic protocol developed by Netscape in the mid-1990s to provide secure communication between web browsers and servers. It was the first widely deployed protocol for encrypting internet traffic. However, due to numerous security vulnerabilities, SSL has been completely replaced by TLS.

Key Insight: When most people today say "SSL certificate," they actually mean a TLS certificate — the term "SSL" has stuck even though the protocol itself is obsolete and dangerous to use.

History of SSL Versions

Why SSL is Insecure

1. POODLE Attack (Padding Oracle On Downgraded Legacy Encryption)

Year: 2014 | Impact: Critical

How POODLE Works:

1. Attacker forces browser to downgrade to SSL 3.0
2. SSL 3.0 uses CBC mode encryption with weak padding
3. Attacker intercepts encrypted data and manipulates it
4. By observing server responses, attacker can decrypt one byte at a time
5. Eventually, session cookies and other sensitive data are recovered

Mitigation: Completely disable SSL 3.0 everywhere

2. Weak Cipher Suites

3. No Forward Secrecy

SSL 3.0 does not support Perfect Forward Secrecy (PFS):

• If the server's private key is compromised, ALL past sessions can be decrypted.
• Modern TLS uses Diffie-Hellman key exchange so even if the private key is stolen, past session keys remain safe.

Detecting SSL in Use

# Check if a server supports SSL 3.0
openssl s_client -connect example.com:443 -ssl3

# If you get a connection, the server is vulnerable!
# Expected result for secure server:
# 140735192382352:error:14094410:SSL routines:
# ssl3_read_bytes:sslv3 alert handshake failure

# Scan for SSL/TLS vulnerabilities
nmap --script ssl-enum-ciphers -p 443 example.com

SSL Certificate Validation Chain

┌─────────────────────────┐
│ Root CA Certificate │
│ (Self-signed, built │
│ into OS/browser) │
└───────────┬─────────────┘
│ Signs
▼
┌─────────────────────────┐
│ Intermediate CA Cert │
│ (Issued by Root CA) │
└───────────┬─────────────┘
│ Signs
▼
┌─────────────────────────┐
│ Server Certificate │
│ (Issued for domain) │
│ example.com │
└─────────────────────────┘

SSL Certificate Contents

An X.509 certificate contains:

Certificate:
Version: 3 (0x02)
Serial Number: 04:00:00:00:00:01:23:45:67:89
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = Let's Encrypt, CN = R3
Validity:
Not Before: Jul 18 00:00:00 2024 GMT
Not After: Oct 16 00:00:00 2024 GMT # ← Certificates expire!
Subject: CN = example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus: 00:d3:5a:7f:...
Exponent: 65537 (0x10001)
X509v3 extensions:
Subject Alternative Name:
DNS:example.com, DNS:www.example.com
CA:FALSE
Key Usage: Digital Signature, Key Encipherment
Extended Key Usage: TLS Web Server Authentication

2. SSH (Secure Shell)

What is SSH?

SSH is a cryptographic network protocol for operating secure remote login, command execution, and other network services over an unsecured network. It was designed as a replacement for Telnet, rlogin, rsh, and rcp — all of which send data (including passwords) in plaintext.

Key Insight: SSH is not just a "secure Telnet." It's a complete secure transport protocol that supports port forwarding, file transfer, X11 forwarding, VPN-like tunneling, and authentication agent forwarding.

SSH Protocol Architecture

SSH uses a three-layer architecture:

┌─────────────────────────────────────────────────────────────┐
│ SSH Connection Layer │
│ Multiplexes multiple channels over one encrypted session │
│ Each channel: interactive shell, tunnel, SCP, SFTP, X11 │
├─────────────────────────────────────────────────────────────┤
│ SSH Authentication Layer │
│ Verifies user identity to the server │
│ Methods: password, public key, host-based, GSSAPI/Kerberos │
├─────────────────────────────────────────────────────────────┤
│ SSH Transport Layer │
│ Handles encryption, integrity, compression │
│ Key exchange, server host key authentication │
│ Algorithms: AES, ChaCha20, SHA-2, ECDH │
├─────────────────────────────────────────────────────────────┤
│ TCP (Port 22) │
└─────────────────────────────────────────────────────────────┘

SSH Connection Flow — Detailed

SSH CLIENT SSH SERVER
| |
|===== Phase 1: TCP Connection ======|
|--- TCP SYN ----------------------->|
|<-- TCP SYN-ACK --------------------|
|--- TCP ACK ----------------------->|
| |
|===== Phase 2: Protocol Version Exchange =====|
|--- "SSH-2.0-OpenSSH_9.6\r\n" ---->
|<-- "SSH-2.0-OpenSSH_8.9\r\n" -----| Must match major version
| |
|===== Phase 3: Key Exchange ==============|
|--- KEXINIT (algorithms list) ----->| Both sides propose algorithms
|<-- KEXINIT (algorithms list) ------|
| (Choose: ECDH, AES-256-GCM, |
| SHA-256, etc.) |
| |
| Diffie-Hellman Key Exchange |
| (Creates shared secret) |
| |
|--- Exchange hash (session ID) ---->| First 16 bytes = SSH session ID
|<-- Exchange hash ------------------|
| |
|===== Phase 4: Server Auth ==============|
|<-- Host key + signature -----------| Server proves identity
| (RSA: 8b:2a:... fingerprint) |
| (ED25519: SHA256:abc... key) |
| |
| Client checks ~/.ssh/known_hosts |
| If unknown: prompts user: |
| "Are you sure you want to continue |
| connecting (yes/no/[fingerprint])?"|
| |
|===== Phase 5: Encryption ON =======|
|--- New Keys message -------------->| All traffic now encrypted
|<-- New Keys message ---------------|
| |
|===== Phase 6: User Authentication ==|
|--- "auth: publickey" ------------->|
|<-- "challenge: sign this data" ----| Server challenges client
|--- "signed challenge" ------------>|
|<-- "auth success" -----------------|
| (Or: "auth password") |
| |
|===== Phase 7: Session =============|
|--- "session open" request -------->|
|<-- "session open confirmed" -------|
|--- "exec 'bash'" or shell -------->|
|<-- Interactive shell session ------|
| |
|===== Phase 8: Channel Close =======|
|--- "close channel" --------------->|
|<-- "close channel" ----------------|
|--- TCP FIN ----------------------->|

SSH Key Authentication — In Depth

Key Pair Generation

# Generate Ed25519 key (recommended)
ssh-keygen -t ed25519 -C "user@example.com"

# Generate RSA key (compatible with older systems)
ssh-keygen -t rsa -b 4096 -C "user@example.com"

# Generated files:
~/.ssh/id_ed25519 # Private key — NEVER share this!
~/.ssh/id_ed25519.pub # Public key — this goes on servers

The Authentication Process (Public Key)

CLIENT SERVER
| |
| Sends: public key fingerprint |
| "I'd like to authenticate as |
| user@host using key SHA256:abc" |
|---------------------------------->|
| |
| Checks authorized_keys: |
| "Does this key exist?" |
| If yes, proceed... |
| |
| Generates random challenge |
|<-- Calculates: sign(challenge) |
| with the known public key |
| OR sends the challenge itself |
| |
| Proves possession of private |
| key by signing the challenge |
|--- (Sends signed challenge) ---->|
| |
| Verifies signature with stored |
| public key. If valid → GRANT |
|<-- "Authentication successful" --|

SSH Key File Format

# Public key format (~/.ssh/id_ed25519.pub)
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIP+W1c... user@example.com
│ │ │
Key type Base64-encoded public key Comment

# Private key format (~/.ssh/id_ed25519) — PEM
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAA...
-----END OPENSSH PRIVATE KEY-----

SSH Port Forwarding (Tunneling)

SSH can tunnel arbitrary TCP traffic through the encrypted connection, providing ad-hoc VPN-like functionality.

Local Port Forwarding (Client → Server → Target)

# Syntax: ssh -L [local_addr:]local_port:target_addr:target_port user@host
# Example: Forward local 8080 to internal server's web interface
ssh -L 8080:intranet.internal:80 user@jumpbox.example.com

# Access: http://localhost:8080 → encrypted tunnel → jumpbox → intranet:80

┌──────────┐ :8080 (local) ┌──────────┐ :80 ┌────────────┐
│ Your │◄────────────────────│ SSH │──────────────►│ Intranet │
│ Browser │ (encrypted) │ Tunnel │ (decrypted) │ Web Server │
└──────────┘ └──────────┘ └────────────┘

Remote Port Forwarding (Server → Client → Target)

# Syntax: ssh -R [remote_addr:]remote_port:target_addr:target_port user@host
# Example: Expose local web server to the internet via a public server
ssh -R 8080:localhost:3000 user@public-server.com

# Remote users access: public-server.com:8080 → tunnel → your localhost:3000

┌──────────┐ :3000 ┌──────────┐ :8080 ┌────────────┐
│ Users │ (local) │ Public │◄──────────────│ Your │
│ Browser │◄──────────────────│ Server │ (encrypted) │ Local Dev │
└──────────┘ └──────────┘ └────────────┘

Dynamic Port Forwarding (SOCKS Proxy)

# Creates SOCKS proxy on local port 1080
ssh -D 1080 user@jumpbox.example.com

# Configure your browser to use SOCKS5 proxy at localhost:1080
# All browser traffic goes through the SSH tunnel

SSH Client Configuration (~/.ssh/config)

# ~/.ssh/config — organize your connections

# Default settings for all hosts
Host *
ServerAliveInterval 60
ServerAliveCountMax 3
Compression yes
Protocol 2

# Personal server
Host myserver
HostName 203.0.113.10
Port 2222 # Non-standard port
User john
IdentityFile ~/.ssh/id_ed25519_personal
ForwardAgent yes

# Jump box to access internal network
Host bastion
HostName bastion.example.com
User admin
IdentityFile ~/.ssh/id_ed25519_work
LocalForward 8080 internal-dashboard:80
LocalForward 9090 grafana.internal:3000

# GitHub
Host github.com
User git
IdentityFile ~/.ssh/id_ed25519_github
HostName github.com

# Connection Sharing (reuse connection for speed)
Host *
ControlMaster auto
ControlPath ~/.ssh/control-%r@%h:%p
ControlPersist 10m

SSH Commands Reference

# Basic login
ssh user@hostname
ssh -p 2222 user@hostname # Custom port
ssh -i ~/.ssh/special_key user@hostname # Specific key

# Run a command remotely
ssh user@host "ls -la /var/log"
ssh user@host "tail -f /var/log/syslog" # Follow logs

# Secure file copy (SCP)
scp file.txt user@host:~/
scp -r /local/dir user@host:/remote/dir
scp user@host:/remote/file.txt ./local/

# SFTP (interactive file transfer)
sftp user@hostname
> ls
> get remote-file.txt
> put local-file.txt
> bye

# Agent forwarding (forward SSH keys through jump host)
ssh -A user@bastion.example.com
# Then from bastion, SSH to internal hosts using your local keys

# X11 Forwarding (run GUI apps remotely)
ssh -X user@hostname
firefox & # Firefox GUI appears locally

# SSH key management
ssh-keygen -t ed25519 -C "description"
ssh-copy-id user@hostname # Copy key to server
ssh-add ~/.ssh/id_ed25519 # Add key to agent
ssh-agent -s # Start agent
ssh-add -l # List loaded keys

# SSH audit
ssh-audit example.com # Check SSH server config

SSH Encryption Algorithms

SSH Security Best Practices

# /etc/ssh/sshd_config — Hardened SSH Server Configuration

# Basic
Port 2222 # Change from default 22 (reduces bots)
Protocol 2 # Only SSH2 (SSH1 is insecure)

# Authentication
PermitRootLogin no # NEVER allow root direct login
PubkeyAuthentication yes # Key-based auth
PasswordAuthentication no # Disable password auth
AuthenticationMethods publickey # Only allow public key
MaxAuthTries 3 # Limit login attempts
LoginGraceTime 30 # Timeout for login

# Security
AllowUsers alice bob admin-specific # Whitelist users
DenyUsers root guest # Explicitly deny
AllowGroups ssh-users # Group-based access
ClientAliveInterval 300 # Check client is alive (5 min)
ClientAliveCountMax 2 # Drop after 2 missed pings
MaxSessions 4 # Prevent session exhaustion
MaxStartups 3:50:10 # Rate limit connections

# Forwarding
X11Forwarding no # Disable unless needed
AllowTcpForwarding yes # Enable for tunnels
AllowAgentForwarding yes # Enable only if needed
PermitTunnel no # Disable tunnel devices

# Logging
SyslogFacility AUTH
LogLevel VERBOSE # Log fingerprints

SSH Troubleshooting

# Verbose connection (use -vvv for maximum detail)
ssh -vvv user@hostname

# Check SSH server status
systemctl status sshd
sshd -t # Test configuration

# Check for listening SSH
netstat -tlnp | grep :22

# Scan SSH key fingerprints
ssh-keyscan -t ed25519 example.com

# Test SSH connection
nc -zv hostname 22

# Known hosts issues
ssh-keygen -R hostname # Remove host key
ssh-keyscan -H hostname >> ~/.ssh/known_hosts # Add key

# Check authorized_keys permissions
chmod 700 ~/.ssh # Directory
chmod 600 ~/.ssh/authorized_keys # File
chmod 600 ~/.ssh/id_ed25519 # Private key
chmod 644 ~/.ssh/id_ed25519.pub # Public key

3. HTTPS (Hypertext Transfer Protocol Secure)

What is HTTPS?

HTTPS is simply HTTP running over TLS. It is NOT a separate protocol — it is the combination of HTTP (for web content) and TLS (for security). Every HTTPS connection begins with a TLS handshake, after which all HTTP data is encrypted.

Key Insight: HTTPS is the single most important security measure for any website. It protects user data, verifies site identity, and is now required by browsers and search engines.

HTTPS vs HTTP — Behavior Comparison

Raw HTTP (Port 80 — Plaintext)

Client → Server (visible to anyone sniffing):
GET /login HTTP/1.1
Host: example.com
Cookie: session=abc123
Content: username=alice&password=secret1
← ALL visible in packet capture!

HTTPS (Port 443 — Encrypted)

Client → Server (sniffer sees gibberish):
t8xJq3kFp9a2Rc4vBn7mWq5yXz1...
← Everything encrypted until decrypted at server

TLS Handshake with HTTPS — Two Variants

TLS 1.2 Handshake (2 Round Trips)

CLIENT (Browser) SERVER (Website)
| |
|======== TCP Handshake (3-way) ========|
|--- SYN ----------------------------->|
|<-- SYN-ACK --------------------------|
|--- ACK ----------------------------->|
| |
|======== TLS 1.2 Handshake (2-RTT) ===|
| |
|--- ClientHello --------------------->| 1st RTT starts
| TLS 1.2 |
| Ciphers: [TLS_AES_128_GCM, ...] |
| Random bytes: RAND_CLIENT |
| |
|<-- ServerHello ----------------------|
| TLS 1.2 |
| Cipher: TLS_AES_128_GCM_SHA256 |
| Random bytes: RAND_SERVER |
|<-- Certificate ----------------------|
| (Server's X.509 certificate) |
|<-- ServerHelloDone ------------------|
| |
|--- ClientKeyExchange --------------->|
| PreMasterSecret (encrypted with |
| server's public key) |
|--- ChangeCipherSpec ---------------->|
|--- Finished ------------------------>| 2nd RTT ends
| |
|<-- ChangeCipherSpec -----------------|
|<-- Finished -------------------------|
| |
|======== Application Data ============|
|<==== Encrypted HTTP request/response=> Now fully encrypted

TLS 1.3 Handshake (1 Round Trip)

CLIENT (Browser) SERVER (Website)
| |
|======== TCP Handshake ================|
|--- SYN ----------------------------->|
|<-- SYN-ACK --------------------------|
|--- ACK ----------------------------->|
| |
|======== TLS 1.3 Handshake (1-RTT) ===|
| |
|--- ClientHello --------------------->|
| TLS 1.3 indicator |
| Key share (guess ECDHE share) |
| Supported ciphers |
| (Client guesses server's curve) |
| |
|<-- ServerHello ----------------------| Single round trip!
|<-- Key share + Certificate + Verify |
|<-- Finished -------------------------|
| |
|--- Finished ------------------------->
| |
|<==== Encrypted Data ================>| Faster by 1 RTT!
| |
| TLS 1.3 0-RTT (optional): |
| Client can SEND data IMMEDIATELY |
| with the first handshake message |
| using cached session ticket |

HTTPS Certificate Types

Validation Levels

DV Certificate Process (using Let's Encrypt)

# 1. Install certbot
sudo apt install certbot python3-certbot-nginx

# 2. Obtain certificate
sudo certbot --nginx -d example.com -d www.example.com

# 3. What happens:
# a. Certbot contacts Let's Encrypt CA
# b. Let's Encrypt challenges: prove you control example.com
# c. DNS challenge: add TXT record _acme-challenge.example.com
# OR HTTP challenge: place file at http://example.com/.well-known/acme-challenge/
# d. Let's Encrypt verifies → issues certificate
# e. Certificate stored at /etc/letsencrypt/live/example.com/

# 4. Auto-renewal
sudo certbot renew --dry-run

Wildcard vs SAN Certificate

Web Server HTTPS Configuration

Nginx HTTPS Configuration:

server {
listen 443 ssl http2;
server_name example.com;

# Certificate paths
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

# Modern TLS configuration (Mozilla recommended)
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers off;

# HSTS (HTTP Strict Transport Security)
add_header Strict-Transport-Security "max-age=63072000" always;

# Other security headers
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";

# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
}

# Redirect HTTP → HTTPS
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$server_name$request_uri;
}

Apache HTTPS Configuration:

<VirtualHost *:443>
ServerName example.com

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/example.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/example.com/chain.pem

# Modern TLS
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
SSLHonorCipherOrder off
</VirtualHost>

HTTP Strict Transport Security (HSTS)

HSTS tells browsers to always use HTTPS for a domain, eliminating downgrade attacks.

# In Nginx:
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

# Policy:
# max-age=63072000 → Enforce 2 years
# includeSubDomains → Applies to all subdomains
# preload → Submit to browser's hardcoded HSTS list

HSTS Preload — How Browsers Learn About Your Site Before First Visit:

1. Go to https://hstspreload.org
2. Submit your domain
3. After approval, your domain is hardcoded into Chrome, Firefox, Safari, Edge
4. Browser ALWAYS uses HTTPS — even on the very first visit

Testing HTTPS Setup

# SSL/TLS server test (openssl)
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -text

# Check certificate details
openssl s_client -connect example.com:443 -showcerts

# Check supported TLS versions
openssl s_client -tls1_2 -connect example.com:443 # Check TLS 1.2
openssl s_client -tls1_3 -connect example.com:443 # Check TLS 1.3
openssl s_client -ssl3 -connect example.com:443 # Should FAIL!

# Check cipher suites
nmap --script ssl-enum-ciphers -p 443 example.com

# Online SSL Labs test (industry standard)
# https://www.ssllabs.com/ssltest/analyze.html?d=example.com

# Check certificate expiry
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

# Check HSTS headers
curl -sI https://example.com | grep -i strict

4. IPSec (Internet Protocol Security)

What is IPSec?

IPSec is a suite of protocols that provides security at the IP layer. Unlike TLS (which secures individual applications) or SSH (which secures terminal sessions), IPSec encrypts and authenticates all IP packets in a communication session — securing everything above Layer 3, without requiring any changes to applications.

Key Insight: IPSec operates at Layer 3, which means it protects ALL traffic between two endpoints — TCP, UDP, ICMP, and even the applications running on top — without the applications knowing anything about encryption. It's the invisible security layer.

IPSec Protocol Architecture

┌──────────────────────────────────────────────────┐
│ IPSec System │
│ │
│ ┌────────────────┐ ┌────────────────────────┐ │
│ │ AH (51) │ │ ESP (50) │ │
│ │ Authentication │ │ Encryption + Auth │ │
│ │ (No encryption)│ │ (Most commonly used) │ │
│ └────────────────┘ └────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────┐ │
│ │ IKE (UDP 500) │ │
│ │ Internet Key Exchange — Key Management │ │
│ │ Authentication + Key Generation │ │
│ └──────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────┐ │
│ │ Security Associations (SAs) │ │
│ │ Uni-directional agreement: What + How │ │
│ │ SPI (Security Parameter Index) identifies │ │
│ └──────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────┘

ESP (Encapsulating Security Payload) — Packet Structure

Transport Mode (End-to-End)

Before ESP:
┌─────────────┬─────────────┬───────────────────┐
│ IP Header │ TCP Hdr │ Application │
│ (src/dest) │ (port etc) │ Data │
└─────────────┴─────────────┴───────────────────┘

After ESP (Transport Mode):
┌─────────────┬──────────┬─────────────┬──────────┬──────────────┐
│ IP Header │ ESP Hdr │ TCP Hdr │ App │ ESP Trailer │
│ (same) │ │ (encrypted) │ Data │ + Auth Data │
└─────────────┴──────────┴─────────────┴──────────┴──────────────┘
└─────────── Encrypted ────────────┘
└────────── Authenticated ────────────┘

Original IP header stays intact — can be routed normally.
Used for: Direct host-to-host communication

Tunnel Mode (Site-to-Site)

After ESP (Tunnel Mode):
┌─────────────────┬──────────┬─────────────┬─────────────┬──────────┬──────────────┐
│ NEW IP Header │ ESP Hdr │ ORIG IP Hdr │ TCP Hdr │ App │ ESP Trailer │
│ (gateway src/ │ │ (encrypted) │ (encrypted) │ Data │ + Auth Data │
│ gateway dest) │ │ │ │ │ │
└─────────────────┴──────────┴─────────────┴─────────────┴──────────┴──────────────┘
└─────────────── Encrypted ──────────────────┘
└────────────── Authenticated ─────────────────┘

Entire original IP packet is encrypted within a new outer IP packet.
Used for: Site-to-site VPNs (router-to-router)

IKE (Internet Key Exchange) — Phase 1 & 2

IPSec uses IKEv1 or IKEv2 to establish Security Associations (SAs).

IKEv1 Phase 1 (Main Mode — 6 Messages)

Gateway A Gateway B
| |
|======== SA Negotiation ===========|
|--- SA Proposal (enc, hash, DH) ->|
|<-- SA Selection ------------------|
| |
|======== Diffie-Hellman ===========|
|--- DH Public Key A -------------->|
|<-- DH Public Key B ---------------|
| (Both compute shared secret) |
| |
|======== Authentication ============|
|--- Auth (signature/pre-shared) -->|
|<-- Auth --------------------------|
| |
| Result: IKE SA (ISAKMP SA) |
| Secure channel for Phase 2 |

IKEv1 Phase 2 (Quick Mode — 3 Messages)

Gateway A Gateway B
| |
|--- ESP Proposal + Nonce + Proxy ->|
|<-- ESP Selection + Nonce + Proxy -|
|--- ACK + Commit ----------------->|
| |
| Result: IPSec SA (ESP SA) |
| Actual traffic encryption |

IKEv2 (Simplified — 4 Messages)

IKEv2 reduces the overhead:

1. Request: SA + KE + Ni
2. Response: SA + KE + Nr
(Creates IKE SA + First Child SA in one go)
3. Request: AUTH + ID + SA + TSi + TSr
4. Response: AUTH + ID + SA + TSi + TSr
(Authenticates + creates IPSec SA)

IPSec Configuration Examples

Site-to-Site VPN (Cisco IOS):

! Phase 1 — IKE Policy
crypto isakmp policy 10
encryption aes 256
hash sha256
authentication pre-share
group 14
lifetime 86400

! Pre-shared key
crypto isakmp key MySecretKey123 address 203.0.113.10

! Phase 2 — IPSec Transform
crypto ipsec transform-set AES256-SHA esp-aes 256 esp-sha-hmac
mode tunnel

! Interesting traffic (what to encrypt)
access-list 100 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255

! Crypto Map
crypto map VPN-MAP 10 ipsec-isakmp
set peer 203.0.113.10
set transform-set AES256-SHA
match address 100

! Apply to interface
interface GigabitEthernet0/1
crypto map VPN-MAP

StrongSwan (Linux — open source):

# /etc/ipsec.conf
conn site-to-site
type=tunnel
left=192.168.1.1 # Local gateway
leftsubnet=10.1.1.0/24 # Local network
right=203.0.113.10 # Remote gateway
rightsubnet=10.2.2.0/24 # Remote network
keyexchange=ikev2
ike=aes256-sha256-modp2048
esp=aes256-sha256
dpdaction=restart
auto=start

# /etc/ipsec.secrets
192.168.1.1 203.0.113.10 : PSK "MySecretKey123"

IPSec vs TLS VPN — Comparison

IPSec Troubleshooting

# Show IPSec SAs
ip xfrm state # Linux
show crypto ipsec sa # Cisco IOS
ipsec statusall # StrongSwan

# Show IKE SAs
ip xfrm policy # Linux
show crypto isakmp sa # Cisco IOS
swanctl --list-sas # StrongSwan v2

# Manual ping test through VPN
ping -S 10.1.1.100 10.2.2.100 # Source IP from local subnet

# Debug IPSec
tcpdump -i eth0 esp # Capture ESP packets
tcpdump -i eth0 port 500 # Capture IKE
tcpdump -i eth0 port 4500 # Capture NAT-T

# IPSec counters
ip -s xfrm state # Linux stats

# Ping with DF bit to test MTU issues
ping -M do -s 1472 10.2.2.100 # Don't Fragment, test size

IPSec Issues and Troubleshooting

5. TLS (Transport Layer Security)

What is TLS?

TLS is the successor to SSL and the most widely deployed security protocol on the internet. It provides:

• Confidentiality — Encryption prevents eavesdropping
• Integrity — Tampering is detected
• Authentication — Server (and optionally client) identity is verified

TLS protects virtually all secure internet traffic — HTTPS, email, VoIP, DNS, VPNs, and countless other applications.

Key Insight: TLS 1.3 (2018) is a dramatic redesign from TLS 1.2 (2008). It's faster, simpler, and eliminates entire categories of attacks by removing weak algorithms and unnecessary features.

TLS Version History

TLS 1.2 Handshake — Deep Dive

CLIENT SERVER
| |
|=== Round 1 =============================|
|--- ClientHello ----------------------->|
| Protocol: TLS 1.2 |
| Random: 32 bytes (RANDOM_C) |
| Session ID: (for session resumption) |
| Cipher Suites: |
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384|
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM |
| TLS_RSA_WITH_AES_256_CBC_SHA |
| Compression: null |
| Extensions: SNI, ALPN, EC curves |
| |
|<-- ServerHello -------------------------|
| Protocol: TLS 1.2 |
| Random: 32 bytes (RANDOM_S) |
| Session ID: 0xABC123 |
| Cipher: TLS_ECDHE_RSA_AES_256_GCM_SHA384|
| Compression: null |
| |
|<-- Certificate -------------------------|
| Server's X.509v3 certificate chain |
| (Server cert + intermediates) |
| |
|<-- ServerKeyExchange -------------------|
| ECDHE public key (server share) |
| Named curve: x25519 |
| Signature: signed by server's RSA key |
| |
|<-- ServerHelloDone ---------------------|
| |
|=== Round 2 =============================|
| |
|--- ClientKeyExchange ------------------>|
| ECDHE public key (client share) |
| (Both sides now compute: |
| pre_master_secret = ECDH(shared) |
| master_secret = PRF(pre_master, |
| "master secret", |
| Random_C + Random_S))|
| |
|--- ChangeCipherSpec ------------------>| "From now on, I'm encrypting"
|--- Finished (encrypted with session key)|
| Verifies entire handshake transcript |
| |
|<-- ChangeCipherSpec --------------------|
|<-- Finished (encrypted) ---------------|
| |
|=== Application Data ====================|
|<==== Encrypted HTTP/2 data =============>|
| |
| Key Derivation: |
| client_write_key = PRF(master, ...) |
| server_write_key = PRF(master, ...) |
| client_write_IV = PRF(master, ...) |
| server_write_IV = PRF(master, ...) |

TLS 1.3 Handshake — Deep Dive (1-RTT + 0-RTT)

CLIENT SERVER
| |
|=== Round 1 (1-RTT) ======================|
|--- ClientHello ----------------------->|
| Protocol: TLS 1.3 "supported versions" |
| Random: 32 bytes |
| Cipher Suites: ONLY AEAD: |
| TLS_AES_128_GCM_SHA256 |
| TLS_AES_256_GCM_SHA384 |
| TLS_CHACHA20_POLY1305_SHA256 |
| Key Share: ECDHE client share |
| (GUESSES the curve — x25519) |
| PSK Key Exchange Modes (if resuming) |
| Extensions: SNI, ALPN, supported_vers |
| |
|<-- ServerHello -------------------------|
| Protocol: TLS 1.3 |
| Random: 32 bytes |
| Cipher: TLS_AES_128_GCM_SHA256 |
| Key Share: ECDHE server share |
| (Both compute key NOW) |
| |
| EncryptedExtensions |
| CertificateRequest (if mutual TLS) |
| |
| Certificate (encrypted) |
| CertificateVerify (encrypted) |
| Finished (encrypted) |
| |
| [Server can start sending data] |
| |
|--- Certificate (if mTLS) -------------->|
|--- CertificateVerify (if mTLS) ---------|
|--- Finished --------------------------->|
| |
| <=== 1-RTT done — Data flows! ===========>|
| |
|=== 0-RTT (Early Data — Optional) ========|
| |
| If client has cached session ticket: |
|--- ClientHello + 0-RTT Early Data ---->>| DATA SENT IMMEDIATELY!
| (Encrypted with PSK) | No waiting for handshake!
| |
| WARNING: 0-RTT data is vulnerable |
| to replay attacks! Only safe for |
| idempotent requests (GET, not POST). |

TLS Cipher Suite Components

A cipher suite defines all cryptographic algorithms used in a TLS session:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
│ │ │ │ │
│ │ │ │ └── PRF/Hash: SHA-384
│ │ │ └─────────── Encryption: AES-256-GCM
│ │ └───────────────────────── Auth: RSA signature
│ └──────────────────────────────── Key Exchange: ECDHE
└───────────────────────────────────── Protocol: TLS

TLS 1.2 Cipher Suites (Many — 30+)

┌────────────────────────────────────────────┬──────────────────────┐
│ Cipher Suite │ Security │
├────────────────────────────────────────────┼──────────────────────┤
│ TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 │ Excellent │
│ TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 │ Excellent │
│ TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 │ Good (DHE slower) │
│ TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 │ CBC (constant time?)│
│ TLS_RSA_WITH_AES_128_GCM_SHA256 │ No PFS (static RSA)│
│ TLS_RSA_WITH_AES_128_CBC_SHA │ Weak │
│ TLS_ECDHE_RSA_WITH_RC4_128_SHA │ RC4 — broken │
│ TLS_RSA_WITH_3DES_EDE_CBC_SHA │ 3DES — sweet32 │
│ TLS_ECDH_anon_WITH_AES_128_CBC_SHA │ Anonymous │
│ TLS_DH_anon_WITH_AES_128_GCM_SHA256 │ Anonymous │
└────────────────────────────────────────────┴──────────────────────┘

TLS 1.3 Cipher Suites (Only 5 — Simplified)

┌─────────────────────────────────────┬──────────────────────┐
│ Cipher Suite │ Status │
├─────────────────────────────────────┼──────────────────────┤
│ TLS_AES_128_GCM_SHA256 │ Mandatory │
│ TLS_AES_256_GCM_SHA384 │ Mandatory │
│ TLS_CHACHA20_POLY1305_SHA256 │ Recommended │
│ TLS_AES_128_CCM_SHA256 │ Optional │
│ TLS_AES_128_CCM_8_SHA256 │ Limited use │
└─────────────────────────────────────┴──────────────────────┘

Key Exchange Comparison

Why PFS (Perfect Forward Secrecy) Matters:

• Without PFS: If someone records your traffic today and later steals your server's private key, they can decrypt everything.
• With PFS: Each session uses a unique, ephemeral key. Stealing the private key later lets you impersonate the server but NOT decrypt past traffic.

TLS Extensions

TLS Configuration Hardening

# TLS 1.3 only (most secure, least compatible)
ssl_protocols TLSv1.3;

# TLS 1.2 + 1.3 (good balance, widely compatible)
ssl_protocols TLSv1.2 TLSv1.3;

# NEVER enable (deprecated/insecure):
# SSLv2, SSLv3, TLSv1.0, TLSv1.1

# TLS 1.2 cipher selection (prefer PFS, AEAD)
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers on;

# TLS 1.3 ciphers are fixed (no configuration needed)

# Disable TLS compression (CRIME/BREACH attack)
ssl_compression off;

# OCSP stapling
ssl_stapling on;
ssl_trusted_certificate /path/to/chain.pem;

TLS Performance Comparison

Real-World Performance Impact:

Connection from New York → Sydney (~200ms RTT):
Without TLS: TCP handshake = 200ms
TLS 1.2: TCP + 2 RTT handshake = 200ms + 400ms = 600ms before data
TLS 1.3: TCP + 1 RTT handshake = 200ms + 200ms = 400ms before data
TLS 1.3 + 0-RTT: TCP handshake = 200ms, data sent immediately = 200ms
QUIC (HTTP/3): 0-RTT, no TCP = 0ms additional

TLS Commands & Tools

# OpenSSL toolkit — Swiss Army Knife for TLS
# Connect to server and show certificate
openssl s_client -connect example.com:443 -showcerts

# Connect with specific TLS version
openssl s_client -tls1_3 -connect example.com:443
openssl s_client -tls1_2 -connect example.com:443

# Show supported cipher suites
openssl ciphers -v | sort

# Generate a self-signed certificate
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem \
-days 365 -nodes -subj "/CN=example.com"

# Check certificate dates
openssl x509 -in cert.pem -noout -dates

# Convert certificate formats
openssl x509 -in cert.pem -outform der -out cert.der # PEM → DER
openssl x509 -in cert.der -inform der -out cert.pem # DER → PEM

# Generate CSR (Certificate Signing Request)
openssl req -new -newkey rsa:2048 -nodes -keyout private.key -out request.csr

# Test TLS with nmap
nmap --script ssl-enum-ciphers -p 443 example.com
nmap --script ssl-cert -p 443 example.com
nmap --script ssl-heartbleed -p 443 example.com

# curl with TLS testing
curl -v https://example.com
curl --tlsv1.3 https://example.com
curl --tls-max 1.2 https://example.com

# Test with testssl.sh (third-party tool)
testssl.sh https://example.com

Common TLS Attacks & Mitigations

TLS Applications Beyond HTTPS

Complete SSL/TLS Comparison Summary