BPP Guardian: We Built a Firewall to Attack Ourselves

The Problem with Testing Anti-Censorship Tools

How do you test a protocol designed to evade state-level firewalls when you don't have access to a state-level firewall?

Most anti-censorship projects rely on indirect evidence: "We deployed in China, and users report it works." That's useful but deeply unsatisfying from an engineering perspective. It tells you nothing about which heuristics are passing, nothing about edge cases, and nothing about whether the next GFW update will break everything overnight.

I wanted something better. I wanted to test BPP against a DPI system that uses the same techniques as the Great Firewall, the Iranian filtering infrastructure, and Russia's TSPU but one that I control, can instrument, and can iterate against.

So I built one.

---

Meet BPP Guardian

Guardian is a full DPI proxy engine written in Go. It sits between the BPP client and server, intercepts every packet, and runs six heuristic checks inspired by documented techniques from real-world censorship systems. It has a PostgreSQL backend for logging and a React dashboard for real-time visualization.

It's designed as an adversary. Its entire purpose is to catch BPP traffic. If it can't if BPP traffic passes through without triggering a single alert then the protocol's evasion is empirically validated.

Think of it as a sparring partner that fights dirty.

---

The Six Heuristics

I spent weeks reading GFW research papers, OONI measurement reports, and the reverse-engineering work of projects like gfw.report before designing Guardian's detection engine.

1. Entropy Flatline

Guardian calculates Shannon entropy on the first kilobytes of each connection. If the entropy is above 7.95 bits/byte that near-perfect randomness you get from raw encrypted data it gets flagged. Real TLS traffic sits around 7.3 7.8 because of structured headers and record framing.

2. Active TLS Probing

Guardian doesn't just passively watch it actively challenges suspicious TLS connections. When it sees a TLS ClientHello, it attempts a session re-establishment challenge. A real web server responds predictably. Most proxy implementations either fail or respond in subtly wrong ways.

3. Cadence Center of Gravity

Guardian analyzes the distribution of packet sizes and inter-arrival times, looking for mathematical regularity. Real traffic has organic variation. VPN tunnels tend to produce packets at regular intervals with uniform sizes. Guardian calculates the "center of gravity" of the packet cadence distribution. If it's too tight too mathematically perfect the connection gets flagged.

4. SNI/IP Mismatch (REALITY Guards)

Guardian extracts the SNI from the TLS ClientHello and performs a DNS A/AAAA lookup. If the SNI says www.google-analytics.com but the actual destination IP doesn't resolve to any Google IP range that's a mismatch, and the connection is flagged.

5. Anti-Fragmentation Guard

Some evasion tools fragment the TLS ClientHello across multiple TCP segments to prevent DPI from reading the SNI. Guardian reassembles fragmented ClientHellos and flags connections that use deliberate sub-packet fragmentation because legitimate TLS libraries almost never fragment the ClientHello.

6. uTLS Domain Fronting Signatures

Guardian maintains a database of known uTLS fingerprint sizes associated with domain fronting attempts through major CDN providers. If the ciphertext size and structure match known static uTLS patterns, the connection is flagged.

---

The Architecture

Component	Tech	Role
Proxy Node	Go (1,106 lines)	Intercepts TCP, parses TLS, runs all six heuristics
PostgreSQL	Postgres 15	Stores connection logs, entropy values, heuristic results
Dashboard	React + Vite	Real-time SSE stream of connection analysis

Standing up the whole thing takes one command:

cd bpp-guardian && docker compose up -d --build

Dashboard at localhost:9090. Proxy at localhost:8080.

---

The Results

We deployed the full stack BPP server + BPP client + BPP Guardian in an isolated Docker network, transmitted 500 MB of data across each transport strategy, and analyzed Guardian's logs.

Transport	Entropy	TLS Probe	Cadence	SNI/IP	Anti-Frag	uTLS Sigs	Alerts
XTLS-REALITY	✓	✓	✓	✓	✓	✓	0
VMess	✓	N/A	✓	N/A	✓	✓	0
Trojan	✓	✓	✓	✓	✓	✓	0
Shadowsocks	✓	N/A	✓	N/A	✓	✓	0

Zero alerts across all transports. Every heuristic passed. The Chameleon Engine's disguises hold up under adversarial inspection implementing the same techniques used by state-level firewalls.

---

What Guardian Taught Us

Building your own adversary is a strange experience. There were moments during development where I'd improve Guardian's detection and suddenly BPP would start failing tests. Then I'd go back to BPP, fix the evasion, and Guardian would go quiet again. It was this back-and-forth adversarial loop exactly how the real arms race between censors and circumvention tools plays out, but compressed into days instead of months.

A few lessons from the process:

1. Entropy is the easiest tell. If I could only implement one heuristic, it would be Entropy Flatline. It catches the majority of amateur encrypted tunnels instantly.

2. Active probing is the hardest to beat. REALITY's approach of proxying to a real website is, to my knowledge, the only reliable defense.

3. Multi-heuristic correlation is the future. No single heuristic is a silver bullet. But if a connection has slightly high entropy AND slightly too-regular packet timing AND a suspicious SNI the combination becomes much stronger than any individual signal. That's why the zero-alert result across six heuristics matters.