175+ Domains: How BPP Fakes Your OS's Natural Traffic

The SNI Problem Nobody Talks About

You've encrypted your traffic. You've disguised it as TLS 1.3. Your entropy is perfect. Your protocol mimicry is byte-for-byte accurate. And then a DPI analyst notices something:

"Why are 500 different IP addresses in Tehran all connecting to obfuscation-proxy.example.com at 2 AM?"

The Server Name Indication (SNI) is the Achilles' heel of anti-censorship tools. It's a field in the TLS ClientHello that tells the server which website the client wants to reach and it's transmitted in plain text. Every DPI system in the world can read it.

Most tools either ignore this problem or use a single cover domain. BPP took a radically different approach: make the SNI field actively work for you.

---

OS-Aware Domain Selection

Here's the insight that drives BPP's domain selection: different operating systems talk to different servers as part of their normal operation. A Windows machine regularly contacts settings-win.data.microsoft.com and wns.windows.com. A Mac pings configuration.apple.com and icloud.com. A Linux box reaches archive.ubuntu.com and snapcraft.io.

A DPI analyst who sees a Windows machine connecting to configuration.apple.com will notice. It doesn't belong.

BPP detects the operating system at runtime and selects cover domains that are native to that platform.

Platform	Example Domains	Count
Windows	settings-win.data.microsoft.com, wns.windows.com, www.msftconnecttest.com	~60
macOS/iOS	configuration.apple.com, icloud.com, captive.apple.com	~40
Linux	archive.ubuntu.com, snapcraft.io, pkg.go.dev	~35
Universal	www.google-analytics.com, cdn.jsdelivr.net, s3.amazonaws.com	~40+

Total: 175+ curated domains.

---

Weighted Selection: Not All Domains Are Equal

In real network traffic, not all domains appear with equal frequency. www.google-analytics.com appears in the traffic of nearly every device that opens a web browser. xbox.servicebus.windows.net appears only on machines with Xbox-related services.

BPP assigns weights to domains based on their real-world traffic frequency:

• High weight: Analytics services, CDNs, cloud APIs domains that appear in virtually all traffic
• Medium weight: Platform services, update servers domains that appear regularly
• Low weight: Specialized services domains that appear occasionally

The selection algorithm uses weighted random sampling: high-traffic domains are selected more often, creating a distribution pattern that mirrors real-world traffic.

---

Session Affinity: The 85% Rule

Real applications don't switch servers on every packet. When you open Google Maps, your browser maintains a connection to Google's servers for the duration of your interaction.

BPP implements session affinity: 85% of packets in a session use the same cover domain. The remaining 15% simulate natural domain drift a background service check, a CDN request, a telemetry ping.

This prevents a DPI system from flagging "domain hopping" where every packet goes to a different domain, a behavior that no real application exhibits.

---

Traffic Shaping: Mimicking How Real Apps Breathe

Perfect protocol mimicry with intelligent SNI is still vulnerable to one more analysis: timing.

A VPN tunnel produces uniform traffic at metronomic intervals. This regularity is a fingerprint.

BPP's Traffic Shaping Profiles

Profile	Jitter	Pattern	Use Case
Standard	5 35ms	Irregular bursts (web browsing)	General-purpose communication
Zoom	2 8ms	Consistent small packets	Low-latency real-time chat
Netflix	Variable	Burst/pause cycles	Large file transfers

The jitter values aren't just random they're cryptographically random, generated from crypto/rand. A DPI system analyzing inter-packet timing won't find a predictable PRNG pattern. The timing genuinely looks organic.

---

Constant-Size Padding: Killing Size Analysis

There's one more analysis vector to neutralize: packet size.

BPP's solution is brutal and effective: every single packet is padded to exactly 1024 bytes.

[2 bytes: real data length (big-endian)]
[N bytes: actual data]
[1024 - 2 - N bytes: cryptographic noise (from crypto/rand)]

This entire 1024-byte block is then encrypted and obfuscated. Every packet on the wire is the same size. A DPI system sees a stream of identical-sized packets as expected for a protocol with fixed record sizes.

---

The Compound Effect

Each of these mechanisms provides partial protection. Together, they create a compound defense that's far stronger than any individual technique.

A DPI system would need to simultaneously:

1. Break the protocol mimicry (it can't the bytes are correct)
2. Distinguish the entropy (it can't it matches the real protocol)
3. Flag the SNI (it can't the domain belongs to the OS's normal traffic)
4. Analyze the timing (it can't the jitter is genuinely random)
5. Classify by size (it can't all packets are 1024 bytes)

No single defense is unbreakable. But breaking all five simultaneously? That's the point.