The domain allowlist, enforced against both CONNECT targets and TLS SNI, is the primary security control. Port restrictions are defense-in-depth.
The HTTP CONNECT method creates a blind TCP tunnel. From Squid's official documentation:
"It is important to notice that the protocols passed through CONNECT are not limited to the ones Squid normally handles. Quite literally anything that uses a two-way TCP connection can be passed through a CONNECT tunnel."
This is why Squid's default ACL starts with deny CONNECT !SSL_Ports.
Industry consensus: Port-based filtering is increasingly obsolete.
From Palo Alto Networks: "Developers began tunneling application traffic through common ports like 80 and 443 to bypass restrictive firewalls. This rendered port-based filtering largely ineffective."
Bypass techniques are well-documented:
- SSH over 443: Run
sshd -p 443, tunnel anything (documented extensively) - SSLH multiplexing: Same port serves SSH and HTTPS based on protocol detection
- HTTP tunneling tools: chisel, wstunnel, cloudflared work over "allowed" ports
Even Nmap's reference-guide source notes historical firewall flaws—Zone Alarm allowed any UDP from port 53, Windows IPsec filters allowed all traffic from port 88.
1. Squid's official security guidance (SecurityPitfalls):
"Safe_Ports prevents people from making requests to any of the registered protocol ports. SSL_Ports along with the CONNECT ACL prevents anyone from making an unfiltered tunnel to any of the otherwise safe ports."
2. CMU SEI recommends port-based egress filtering (Best Practices):
- Block SMB (445)—would have limited WannaCry spread
- Restrict DNS (53)—prevents participation in DDoS like 2016 Dyn attack
- Block IRC (6660-6669)—common C2 channel
3. Defense-in-depth principle: Forces attackers to use sophisticated techniques rather than obvious ports.
Port restrictions fail when attackers control infrastructure on port 443. AWF validates both the plaintext CONNECT target and the TLS ClientHello SNI:
CONNECT attacker.com:443
→ Port 443? ✓
→ Domain in allowlist? ✗ DENIED
CONNECT allowed-cdn.example:443
→ CONNECT domain in allowlist? ✓
→ TLS SNI attacker.example? ✗ TERMINATED
For normal HTTPS traffic, Squid peeks only at the ClientHello and then splices the connection without decrypting application data. Missing or non-allowlisted SNI fails closed. Trusted AWF-owned sidecars retain their separately scoped egress policies.
Even this has limits. An attacker can still misuse a compromised or intentionally allowlisted origin. DNS tunneling can exfiltrate data through allowed DNS servers by encoding data in queries. These risks require additional controls beyond domain and SNI filtering.
| Layer | What It Blocks | Bypass Method |
|---|---|---|
| Port restriction | SSH:22, SMTP:25, DB:3306 | Run service on 443 |
| CONNECT + SNI allowlist | Non-whitelisted TLS destinations and CDN fronting | Compromise or misuse an allowed origin |
| SSL Bump/DPI | Malicious content on allowed domains | Performance cost, cert complexity |
Port restrictions are not security theater, but not primary security either. They:
- Block opportunistic attacks using standard ports
- Increase attacker effort and sophistication required
- Align with NIST SP 800-41 egress filtering guidance
AWF's security relies on the domain and SNI allowlist. Keep it minimal. Port restrictions are a useful secondary layer but will not stop misuse of an origin that is intentionally allowlisted.