WAFs, firewalls, mTLS, and HSTS

Your firewall blocks port scans and obvious nonsense. But the attacker is sending valid HTTP requests to port 443. The firewall passes them all — it cannot see inside the encrypted TLS payload. You need a different tool for application-layer attacks, one that understands HTTP: a WAF.

Firewalls vs WAFs: the fundamental difference. A firewall (L3/L4) inspects IP and TCP headers: source IP, destination port, TCP flags. It blocks port scanning, IP spoofing, and protocol violations. It cannot see inside encrypted HTTPS payloads. A Web Application Firewall (WAF, L7) inspects HTTP request/response content after TLS termination: headers, query parameters, request bodies — matching against known attack patterns (SQL injection, XSS, path traversal). A WAF must see plaintext to inspect it, so it terminates TLS at the edge or sits on the origin behind TLS termination. Both are necessary: the firewall stops network-level nonsense, the WAF stops application-level attacks.

WAF detection modes. Signature-based: match against a database of known attack patterns. OWASP ModSecurity Core Rule Set (CRS) contains patterns like union select (SQL injection), <script> (XSS), and ../../../etc/passwd (path traversal). Fast and low false positives on known traffic, but misses zero-days and obfuscated patterns (e.g., un/**/ion select).

Anomaly/ML-based: model normal traffic, flag statistical outliers. Catches novel attacks but requires tuning — too strict and legitimate users get blocked, too loose and attacks slip through.

OWASP CRS anomaly scoring. Each rule in OWASP CRS assigns a score (1–8 points). A request is blocked when the total score >= 5. Paranoia Levels (PL1–PL4) control how many rules are active: PL1 is permissive (fewer false positives, misses some attacks); PL4 is strict (catches more, but blocks more legitimate users too).

WAF tuning in production. Start at PL1 in detection mode (log and alert but do not block) for 1–2 weeks. Collect baseline metrics: anomaly score distribution on real traffic, rule hits by category. Then raise the paranoia level and observe the false-positive rate. If false positives exceed tolerance, tune rules: whitelist known false positives, adjust scoring weights, or exclude low-confidence rules. Target: block 95%+ of attacks while affecting less than 0.1% of real users.

mTLS for service-to-service identity. Mutual TLS: both client and server present X.509 certificates to each other, not just the server to the client. In a service mesh (Istio, Linkerd), every sidecar proxy uses mTLS to talk to peer sidecars, enforcing zero-trust: a request from Pod A to Pod B is encrypted and authenticated. SPIFFE (Secure Production Identity Framework for Everyone) issues short-lived certificates (often ~1-hour expiration) via an SDS (Service Discovery Service) that the sidecar loads and rotates automatically. The sidecar key never leaves the local container; the control plane refreshes the cert out-of-band.

Cost: each new connection handshake adds 20–50 ms on older hardware; cert rotation adds operational complexity. Benefit: lateral movement is prevented even if the container network is compromised.

TLS stripping and HSTS. SSL stripping (Moxie Marlinspike, 2009): a MITM keeps the user on HTTP while talking HTTPS to the real server, decrypting both directions. The user never knows they are on plaintext. Defense: HTTP Strict Transport Security (HSTS) — the header Strict-Transport-Security: max-age=31536000 tells the browser “only use HTTPS for this origin for the next year.” But the header is delivered over HTTP in the first response — if the first request is stripped, the header is stripped too.

HSTS preload. A browser-shipped list of domains that must always be HTTPS, enforced before the domain is ever visited. Google, Firefox, Chrome, and Safari ship preload lists. You request inclusion for your domain; it ships in the next browser release. From then on, HTTPS is enforced even for first-time visitors. Minimum max-age for preload: 31,536,000 seconds (1 year). The 1-year requirement exists because preload ships in browser releases (4-week cycles for Chrome) — a shorter max-age would expire before users install the next update.