whitelist-bypass tunnels internet traffic through commercial video-calling platforms, aimed at networks that permit an approved list of domains and block everything else. Tunnelling over WebRTC isn’t new. What caught my attention is what this project chooses to ride.

Whitelist censorship is a different problem from a blocklist. A blocklist leaves the rest of the internet reachable, so a proxy on some unremarkable host usually gets you out.

Advertisement

A whitelist inverts that. Only approved destinations resolve and connect; everything else fails. To get through, your traffic has to be one of the approved destinations, not merely look unlike a blocked one.

whitelist-bypass’s answer is to send your data to a video-calling service the censor has already allowed. A device on the censored network places what looks like an ordinary call to VK Call, Yandex Telemost, or WB Stream; a machine on the free internet answers, and the traffic you actually want rides inside that call.

It all rests on the platform’s media server sitting on the approved list. Whether a given platform is permitted, and stays permitted, is a fact about one network at one moment. The tool doesn’t control it.

Two tunnels, and why there are two

The project gives you two ways to carry data through the call, and the second one exists because the first can be throttled.

DC mode opens a WebRTC data channel – an SCTP stream, the same primitive a browser uses for peer-to-peer file transfer – and pushes a SOCKS5 tunnel through it. Your traffic becomes data-channel payload, relayed by the platform’s media server like any other call data.

Video mode does the same job, but encodes the data onto a published VP8 video track instead. It’s there for a reason the repository makes clear: some media servers rate-limit data channels while passing video freely, and on at least one supported platform the publisher’s track has to be video at all.

Advertisement

So when the data channel gets squeezed, the tunnel moves into the one stream a video call can’t do without. Both modes share the same framing and multiplexing above the transport, so the only difference is which stream carries the bytes.

The recommended deployment runs headless on both ends: pure Go on the Pion WebRTC stack, talking to the platform’s media server directly with no browser in the loop.

What is actually in the repository

I cloned the current main branch (commit 747f8f2, 3 September 2026) and read the source rather than the description of it. The tunnel is real code, not a README promise.

The shared relay under relay/ implements the SOCKS5 proxy, the data-channel and VP8 tunnels, a connection multiplexer and an obfuscator. Separate headless creators handle each platform – vk, telemost, wbstream and dion – each its own Go module that creates or joins a call through the platform’s API without a browser.

The obfuscator is a deliberate choice. It derives a secret from the call’s join link, hashes it with SHA-256, and uses that key with XChaCha20-Poly1305 authenticated encryption and random per-message nonces; it also pads keepalive frames.

So the payload inside the call is encrypted independently of the platform’s own transport security, keyed by something both ends already share: the link used to join the call. Any smoothing of the video track’s timing is separate transport code, not part of the obfuscator.

It’s genuinely multi-platform. The joiner – the client on the censored side – targets Android, iOS and Linux; the creator, on the free side, targets Windows, macOS and Linux. On Android it runs as a system VPN, so all traffic flows through the call.

iOS is more involved. The source tree carries two forms: a proxy app that exposes a local SOCKS5 endpoint another app points at, and a VPN app that uses Apple’s Network Extension capability for system-wide routing.

Only the proxy build ships as a prebuilt IPA in the v0.3.8 release. The VPN app is in the source and its build target is documented, but it needs signing and that capability, so if you want it you’ll be building and signing it yourself.

Where it sits among WebRTC tunnels

Carrying a tunnel over WebRTC is well-trodden ground. Pion’s own ecosystem list includes Tor’s Snowflake, weron, rtctunnel and a WebRTC socket proxy, and whitelist-bypass sits on that same list. So the interesting part isn’t the transport but the carrier it rides.

Snowflake, the closest well-known relative, uses volunteer browsers as ephemeral WebRTC proxies to reach Tor. whitelist-bypass instead points at named commercial calling services and leans on them being individually whitelisted by the censor.

That’s a sharper bet, and a more fragile one. It works precisely because a specific platform is on the approved list, and it stops working the moment that platform comes off it. The video-track fallback is the same logic one level down: when the cheap channel is squeezed, you move to the stream the service can’t throttle without breaking the calls it exists to carry.

Darknet has covered the covert-tunnel idea before, from the enterprise side. ProxyBlob runs a SOCKS5 tunnel over Azure Blob Storage, betting that a cloud endpoint is too ordinary to block. whitelist-bypass makes the same structural move against a stricter filter, with a consumer platform as the cover instead of a cloud service.

The claim to be careful about

The project says that to deep-packet inspection the tunnel “looks like a normal video call”. That’s the load-bearing claim, and it’s the one this article can’t verify.

So does it actually look like a video call on the wire? Confirming that needs a real censored network, live DPI equipment, and traffic analysis over time, none of which a source review gives you.

There are reasons for genuine caution. A real video call has a characteristic traffic shape: bitrate, packet timing, the rhythm of a codec reacting to a moving image. A tunnel that’s pushing bulk data through a VP8 track is under pressure to depart from that shape.

The project does offer configurable VP8 pacing and padded keepalive frames, controls plainly aimed at the problem. But whether the result survives statistical traffic analysis, rather than simple protocol matching, is an empirical question and an arms race. It isn’t a property you can read off the code, so I’d treat “looks like a video call” as the project’s design goal, not a measured result.

Two smaller cautions follow from the design. It depends entirely on the carrier platform staying whitelisted, so it’s only ever as durable as that political fact. And the obfuscator keys on the join link, so a session is only as secure as that link’s distribution: anyone who has the link has the key.

Maturity and provenance

The repository is MIT-licensed, sits at around 1,630 stars and 100 forks, and is actively developed: seventeen releases, the most recent (v0.3.8) in July 2026, commits running into September, six contributors led by one. That’s real momentum for a project barely six months old.

The 0.3.x version line is honest about where it stands, too – software shipped through release artefacts and still changing, not a settled release.

There’s one practical consequence of the anti-censorship purpose. The project’s public contact is a Telegram channel rather than a corporate page, and its authorship is a handful of pseudonymous GitHub accounts. For a tool whose users may be on the wrong side of a national firewall, that’s unremarkable.

It does mean, though, that the repository points at no named organisation, no identified maintainer and no published security audit. Anyone deploying it for real is trusting the code and the build, and should read both.

Reviewed 6 September 2026 against commit 747f8f2. I verified the source-level mechanism, build surface, release history and dependency choices directly; I didn’t run it against a live target, and its DPI-resistance claim is the project’s own, not independently confirmed here.

You can find whitelist-bypass here: https://github.com/kulikov0/whitelist-bypass

Advertisement