Security — Cheat Sheet
Computer Networks · 5 topics. Download the PDF or the Instagram carousel and share it.
TLS Handshake Deep-Dive
The TLS handshake is the cryptographic negotiation that establishes a secure, authenticated session before any application data is sent — combining asymmetric crypto for key exchange with symmetric crypto for bulk encryption.
- ✓TLS 1.3 completes in 1 RTT vs 2 RTT for TLS 1.2, directly reducing HTTPS connection latency.
- ✓TLS 1.3 mandates forward secrecy via ECDHE — RSA key transport (no forward secrecy) is removed.
- ✓mTLS authenticates both client and server — essential for zero-trust and service mesh architectures.
- ✓0-RTT resumption saves a round-trip but is vulnerable to replay attacks — restrict to idempotent requests.
- ✓The certificate in TLS 1.3 is encrypted — an eavesdropper cannot determine the server identity from the handshake.
// TLS 1.3 — 1-RTT Handshake
// ─────────────────────────────────────────────────────────
// Client Server
// │ │
// │── ClientHello ────────────────▶│
// │ (supported ciphers, │
// │ key_share: ECDH pub-key, │
// │ supported_versions: TLS1.3) │
// │ │
// │◀─ ServerHello ─────────────────│
// │ (chosen cipher, │
// │ key_share: ECDH pub-key) │
// │◀─ {Certificate} ───────────────│
// │◀─ {CertificateVerify} ─────────│ (server signs handshake transcript)
// │◀─ {Finished} ──────────────────│
// │ │
// │── {Finished} ─────────────────▶│
// │ │
// │══ Application Data (AES-GCM) ══│ ← 1 RTT total
//
// Keys derived via HKDF from ECDH shared secret:
// client_write_key, server_write_key, client_write_IV, server_write_IVCertificates & PKI
Public Key Infrastructure (PKI) is the trust hierarchy of Certificate Authorities, digital certificates, and revocation mechanisms that allows a client to verify it is talking to the intended server and not an impersonator.
- ✓An X.509 certificate binds a public key to an identity via a CA's digital signature — proving the server is who it claims to be.
- ✓Trust is hierarchical: Root CA → Intermediate CA → End-Entity cert. Roots are pre-installed in OS/browser trust stores.
- ✓OCSP Stapling eliminates the extra round-trip and privacy leak of traditional OCSP without sacrificing freshness.
- ✓Let's Encrypt issues free 90-day certificates; ACME protocol automates renewal — zero-cost HTTPS for every project.
- ✓A certificate with an invalid chain, expired validity, or revoked status causes browser warnings and failed API calls.
// X.509 Certificate fields (simplified): // ┌────────────────────────────────────────────────────────────────┐ // │ Version : 3 │ // │ Serial Number : 0x4A2B... (unique per CA) │ // │ Signature Alg : sha256WithRSAEncryption │ // │ Issuer : CN=Let's Encrypt R3, O=Let's Encrypt │ // │ Validity : 2026-01-01 → 2026-04-01 (90-day cert) │ // │ Subject : CN=aicancode.org │ // │ Public Key : RSA 2048-bit / EC P-256 │ // │ Subject Alt Names (SAN): aicancode.org, www.aicancode.org │ // │ Key Usage : Digital Signature, Key Encipherment │ // │ CA Signature : <Let's Encrypt signs the above with its key>│ // └────────────────────────────────────────────────────────────────┘ // Inspect a certificate from command line: openssl s_client -connect aicancode.org:443 -showcerts openssl x509 -in cert.pem -text -noout
Firewalls & Packet Filtering
A firewall controls network traffic by inspecting packets and applying rules to allow or deny flows — operating at Layer 3/4 (packet filtering) or Layer 7 (application-aware deep packet inspection).
- ✓Stateless firewalls inspect each packet independently; stateful firewalls track connection state and auto-allow return traffic.
- ✓AWS Security Groups are stateful (instance level); NACLs are stateless (subnet level) — NACLs require explicit rules for both directions.
- ✓A WAF operates at Layer 7 — it can block SQLi, XSS, enforce rate limits, and apply geo-restrictions on HTTP traffic.
- ✓Default-deny posture: block all traffic and explicitly allow only what is needed — never default-allow.
- ✓Firewall rules are evaluated in order; the first matching rule wins. Order matters significantly for ACLs.
// Stateless firewall — each packet checked independently // Rule table (evaluated top-to-bottom, first match wins): // ┌───────┬──────────┬───────────┬──────┬──────────┬────────┐ // │ Rule │ Src IP │ Dst IP │ Port │ Protocol │ Action │ // ├───────┼──────────┼───────────┼──────┼──────────┼────────┤ // │ 100 │ any │ 10.0.0.5 │ 443 │ TCP │ ALLOW │ // │ 200 │ any │ 10.0.0.5 │ 80 │ TCP │ ALLOW │ // │ 300 │ 10.0.0.0 │ any │ any │ any │ ALLOW │ // │ 32767 │ any │ any │ any │ any │ DENY │ // └───────┴──────────┴───────────┴──────┴──────────┴────────┘ // Problem: return traffic (src port 443 → dst port 54321) also needs a rule // Stateful firewall — connection tracking table: // Outbound packet: 10.0.0.10:54321 → 93.184.216.34:443 TCP SYN // ↳ Firewall creates entry: src=10.0.0.10:54321, dst=93.184.216.34:443, state=SYN_SENT // Return packet: 93.184.216.34:443 → 10.0.0.10:54321 TCP SYN-ACK // ↳ Firewall finds entry, state=ESTABLISHED → ALLOW automatically
VPN Deep-Dive
A VPN (Virtual Private Network) creates an encrypted tunnel over a public network, allowing remote devices to securely access private resources as if they were on the same local network.
- ✓A VPN encapsulates and encrypts the original IP packet inside a new packet, creating a secure tunnel over an untrusted network.
- ✓IPsec uses two phases: IKE for key negotiation and ESP for encrypted data transport.
- ✓WireGuard is a modern, minimal VPN protocol (~4,000 lines of kernel code) — faster and simpler than OpenVPN or IPsec.
- ✓Split tunnelling routes only private traffic through the VPN, reducing latency for internet browsing at the cost of reduced visibility.
- ✓AWS Site-to-Site VPN uses IKEv2 with AES-256 to connect on-premise data centres to VPCs over the public internet.
// VPN encapsulation (IPsec Tunnel Mode): // // Original packet: // [ IP Header: 192.168.1.5 → 10.0.0.20 | TCP | HTTP data ] // // After IPsec encapsulation (ESP Tunnel Mode): // [ Outer IP Header: 203.0.113.5 → 198.51.100.1 | ESP Header | ENCRYPTED: [ IP | TCP | HTTP ] | ESP Trailer ] // ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ // VPN client's public IP → VPN gateway IP IPsec header Original packet, encrypted // // Steps: // 1. VPN client intercepts packet destined for 10.0.0.20 // 2. Encrypts it with shared IPsec session key // 3. Wraps in new IP packet to VPN gateway (198.51.100.1) // 4. Gateway receives, decrypts inner packet // 5. Forwards to 10.0.0.20 on private network
DDoS Protection
A Distributed Denial of Service (DDoS) attack overwhelms a target with traffic from thousands of sources simultaneously. Defence requires absorbing volumetric attacks at the edge, filtering protocol attacks at the network layer, and rate-limiting application-layer attacks.
- ✓DDoS attacks are volumetric (flood bandwidth), protocol (exhaust state like SYN flood), or application-layer (HTTP flood).
- ✓SYN cookies prevent SYN flood attacks by encoding connection state in the ISN — no table allocation needed until ACK received.
- ✓Anycast scrubbing centres absorb Tbps-scale volumetric attacks by distributing traffic across global PoPs before it reaches the origin.
- ✓AWS Shield Standard is free and protects against common volumetric attacks; Advanced adds Layer 7 protection and a response team.
- ✓Application-layer DDoS defence: rate limiting (by IP, token), connection limits, WAF rules, and CAPTCHA/JS challenges.
// Category 1: Volumetric — flood the pipe // UDP Flood: send millions of UDP packets to random ports // target receives → checks no listener → sends ICMP "port unreachable" // → exhausts outbound bandwidth replying to spoofed sources // DNS Amplification: send small DNS query with spoofed source IP // open resolver replies with 50× larger response to victim // amplification factor: ~50x // Category 2: Protocol — exhaust connection state // SYN Flood: // Attacker sends thousands of TCP SYN packets (spoofed source IPs) // Server allocates half-open connection state (SYN_RCVD) and sends SYN-ACK // ACK never arrives → connection table fills up → new legitimate SYNs rejected // Mitigation: SYN cookies (server encodes state in ISN, no table needed) // Category 3: Application — mimic legitimate requests // HTTP Flood: thousands of bots send valid GET /search?q=... requests // Server must execute DB queries, render pages // Hard to distinguish from legitimate traffic — requires rate limiting + fingerprinting // Slowloris: open many connections, send headers very slowly // Keeps server connections open → pool exhaustion