Cheat SheetsComputer NetworksSecurity

Security — Cheat Sheet

Computer Networks · 5 topics. Download the PDF or the Instagram carousel and share it.

Cheat Sheet · AiCanCode.org
Security
Computer Networks5 topicsQuick revision reference
1

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 handshake sequence
// 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_IV
2

Certificates & 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 structure
// 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
3

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 vs stateful firewall comparison
// 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
4

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.
IPsec tunnel mode encapsulation
// 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
5

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.
DDoS attack categories and mechanics
// 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
Learn this free with Aria, your AI tutor → AiCanCode.org/learn/computer-networks