Obscura's First Independent Audit by Cure53

Tue, 16 Dec 2025 00:00:00 GMT

We have completed the first independent audit of our macOS app, network extension and protocol conducted by Cure53

Trust, 2-Party Relays, and QUIC

Tue, 11 Feb 2025 00:00:00 GMT

TL;DR

2-Party Relays largely resolve the trust and privacy problem inherent in existing consumer VPNs
QUIC-based VPN protocols blend in with HTTP/3 traffic, bypassing network filters while avoiding the TCP-over-TCP slowdown
We built a new VPN named Obscura based on these two insights, partnering with Mullvad as our exit hop

Consumer VPNs and Trust

The consumer VPN industry has been under growing scrutiny lately – even from government agencies – and for good reason. VPN companies have flooded YouTube with exaggerated claims and scare tactics while also using predatory pricing mechanics. Behind the scenes, these companies are often many-headed hydras with questionable ownership, employing astro-turfing tactics to be top-ranked on “top X VPN of 2025” lists.

Fundamentally, the biggest flaw of existing VPN companies is that they act as your primary man-in-the-middle – seeing both your personal info (connecting IP, email, billing address, etc.) and your browsing history (thanks to TLS’s SNI extension).

Loading graph...

flowchart LR
    user["User"]
    vpn["Traditional VPN"]
    internet["Internet"]
    user -->|knows who you are| vpn -->|...and sees your traffic| internet

As a result, users must rely on their provider’s pinky-promise that none of their data is logged. Yet even a provider that keeps true to its promise can suffer a security breach and be compromised. This is partly why many privacy-conscious folks will tell you not to use a VPN at all (HN discussion).

The 2-Party Relay Solution

What if we can do away with this reliance on trust?

In 2022, Apple’s iCloud Relay team proposed a neat solution (albeit currently limited to just Safari): using a 2-party relay architecture¹.

Loading graph...

flowchart LR
    user["User"]
    firsthop["1st hop"]
    exithop["2nd (exit) Hop"]
    internet["Internet"]
    user -->|knows who you are<br>but never your traffic| firsthop --> exithop -->|sees your traffic<br/>but never who you are| internet

With 2 independent relay hops in sequence, and by end-to-end encrypting your traffic to the 2nd (exit) hop, this design ensures that:

The 1st hop only sees your connecting IP, but can’t decrypt your traffic. It forwards the still-encrypted traffic to the 2nd hop, effectively NAT-ing your connection and masking your IP address from the 2nd hop.
The 2nd (exit) hop connects you to the internet, but never sees your personal info or IP address since it only knows that the connection is coming from the 1st hop.

This splits “who you are” from “what you do”, meaning neither party can tie your identity to your browsing.

This simple yet effective design caught on among those in-the-know. At the IETF, the MASQUE working group² was formed to standardize a version of this design atop HTTP/3³.

Collateral Freedom via Obfuscation

Though VPN companies often tout their “military-grade encryption”⁴, even the strongest encryption won’t help you if your VPN protocol is easily identified and blocked. At worst, this paints a giant target on your back.

I personally experienced this while living in Shanghai, where the Great Firewall not only blocked sites like Wikipedia, Google, and YouTube, but also actively detected and shut down many VPN protocols. These DPI techniques eventually found their way into common networking appliances, which is why – even outside China – you’ll often find your VPN blocked in airports, hotels, or office networks.

Newer, more reliable tools and protocols like v2ray, meek, Shadowsocks, and hysteria2 had a common theme: Collateral Freedom via obfuscation.

The core insight here is that internet censors (and overzealous network admins) generally still want “permitted” traffic to pass through. So if, on the wire, your protocol can blend in with regular internet traffic (either by mimicking HTTP or via Domain Fronting), you’re far less likely to be flagged and blocked.

Obfuscation without TCP-over-TCP meltdown

“Stealth protocols” that obfuscate your traffic over TCP work better, but they suffer from the notorious TCP-over-TCP meltdown problem – leading to significant performance degradation.

Before QUIC (used by HTTP/3), “blending in” often meant tunneling your IP packets over TCP (used by HTTP/1 and HTTP/2). But as explained in “Why TCP Over TCP Is A Bad Idea” (HN discussion), layering TCP connections leads to conflicts in TCP’s retransmission mechanism, resulting in reduced goodput and stuttery performance⁵.

What TCP expects is that it be run over IP – an unreliable network.

This is where QUIC comes in: QUIC is UDP-based, with congestion control moved up the stack. This allows TCP connections to be tunneled via QUIC’s unreliable transmission⁶, avoiding retransmission conflicts altogether.

This was the unspoken insight behind MASQUE’s choice of transport – by using QUIC, tunneling protocols not only blend in with QUIC and HTTP/3 traffic, but also avoid TCP-over-TCP meltdown.

Obscura

These 2 recent advances – the 2-party relay architecture and QUIC’s unreliable transport – are the perfect ingredients for a new generation of VPN services. VPN services that don’t rely on trust for privacy, and that are hard to detect/block without sacrificing performance.

That is exactly what we’ve done with Obscura.

With our 2-party setup, Obscura operates the 1st hop, and we’re proud to partner with Mullvad⁷ who operates the 2nd (exit) hop. As the WireGuard packets are end-to-end encrypted to Mullvad’s servers⁸, we never see any parts of your packet in plaintext (not even SNI). In fact, you can check your connected server’s public key in the Obscura App against those listed on Mullvad’s server page!
For obfuscation, we use quinn-rs’s implementation of RFC 9221 to tunnel WireGuard packets over QUIC. With QUIC’s unreliable transport, we’ve made Obscura much harder to block without sacrificing performance.

As you may have gathered, we take your trust very seriously⁹. So of course our app’s entire source code is on GitHub for you to verify for yourself, and we plan to soon provide reproducible builds of our app¹⁰.

An open and private internet

The internet – our digital commons – deserves to be open and private.

While authoritarian politicians aim to erode our freedoms online, we have the duty as technologists to wield our skills and defend our rights in the digital space. As Eric Hughes wrote in A Cypherpunk’s Manifesto: “We must defend our own privacy if we expect to have any.”

Obscura is our humble contribution to the cause. We hope you’ll check it out, and we’ll see you on the free and open internet. 🏄

Essentially Tor’s HiddenServiceSingleHopMode option ↩
A praise-worthy name! ↩
I was actually fortunate enough to attend the MASQUE working group in-person, where I met fellow nerds who shared tales of their battles with middleboxes and patiently listened to my ramblings about my own attempt at implementing RFC 9298. ↩
Personally, I’d find “djb-grade encryption” a more compelling pitch ↩
I previously wrote about this here ↩
Standardized as RFC 9221 ↩
who we consider one of the most trustworthy VPN providers ↩
Your locally-generated WireGuard pubkey is registered with Mullvad’s servers, and WireGuard’s regular Noise_IK handshake happens between you and the Mullvad exit server. ↩
and we actively work to eliminate the need for trust wherever we can ↩
I previously led the effort to revamp Bitcoin Core’s reproducible builds system to be bootstrappable, work that is referenced by the Tor project. ↩

Obscura Blog