Rendered at 18:31:05 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
tptacek 20 hours ago [-]
Not sure why you'd vibe-code a new VPN protocol, double ratchet or otherwise, when you can just take WireGuard and make a new transport for it.
WireGuard by itself is not a stealth VPN, but the things that make a VPN "stealthy" are all things you'd layer on top of a WireGuard design, not thread through the middle of it. A datagram-based protocol can run under any obscured transport.
We did this at Fly.io when we discovered that, for one reason or another, 5% of our users simply couldn't reliably use UDP. It was a one-day project to run it under WebSockets instead, and that was before coding agents.
drum55 20 hours ago [-]
Wireguard is both really useful and pretty frustrating as a user. As a developer it's amazing that you can do things like relay packets through a bouncer with authentication to get around NAT without ever having to think about the protocol level safety, as a user it's near impossible to configure without the confused "why are no packets working", and as you had here it just doesn't make it through a lot of restrictive networking conditions. I'd love some middle ground between wireguard and tailscale in terms of complexity, their clients have way too much stuff in them.
The parent is obviously just Claude making a fancy website and some sort of unreviewed networking protocol that's dressed up to look as if it's a real project. Github really needs to start showing commit cadence and repo birthdates.
joecool1029 20 hours ago [-]
> I'd love some middle ground between wireguard and tailscale in terms of complexity, their clients have way too much stuff in them.
netbird's a thing to check out if you want an alternative to tailscale you can self-host.
drum55 20 hours ago [-]
Netbird also, at least to me, has much too much stuff in it, perhaps even more. I would love to be able to connect to everything reliably no matter the network, the daemon doesn't need a reverse proxy, Ai agent routing and billing, in browser SSH client, it's all just attack surface. Tailscale allows you to compile a lot of it out as of a couple of weeks ago, but it's still an awful lot of code.
Netbird doesn’t have proper network isolation, due to its shared policy space compared to one gateway interface per customer/organization. Which is not an issue if you are the only user, but if you are building a service for customers to use, and there’s a potential scale up, it will be an issue, either having multi account mode which will results in many resources you need to deploy or containers per customer, or, having them all shared policy that could potentially allow customer to customer access if misconfiguration happens, alternatively, building a gateway in the middle to broker it all but traffic must pass through which is operational cost plus extra latency, and even privacy concerns.
wolrah 5 hours ago [-]
Pangolin is a similar project to Netbird and Tailscale/Headscale in that it's automatically managing wireguard tunnels but it is natively multitenant by design. Even as the super-admin I have to pick which tenant I want to be "connected to" at any given time to access private resources while my SSO still gets me access to all the secured "public" resources no matter what (if any) tenant I'm connected to.
tamimio 3 hours ago [-]
Pangolin is great, I love it and I use it in my homeserver, but it’s only useful in those scenarios, like clients-sites. If your usecase is site-site (Like my case edge computing) it won’t work, also their newt client is being phased out for the cli, and also they don’t have “headless” setup so it can’t be used as a core of your saas for example, it will be a separate extra dashboard to deal with, and last I remember when I checked their license changes if you make $100k revenue. Headscale and tailscale clients also have single tailnet per server, and is policy file based. What I opt for in my use case (think of robotics and embedded) is iroh and build from scratch, since none of the existing solution worked well, the closest was netbird besides the issues I had above.
radlad 15 hours ago [-]
Maybe check out Nebula? (I'm involved in the project.)
nagaiaida 7 hours ago [-]
yeah, seconded. i'm always shocked people leave nebula out of discussions like this
tamimio 19 hours ago [-]
Which is why I am building my stuff around iroh instead.
aborsy 19 hours ago [-]
If you wrap wireguard or build a layer on top of it, it's no longer wireguard that first listens to packets on public interface, it's your wrapper. The security properties of wireguard don't hold (potential for RCE before packets reach wireguard). That's a problem with projects like wstunnel or udp2raw.
You want wireguard to be the software that takes the packets first.
aboardRat4 19 hours ago [-]
>The security properties of wireguard don't hold
That's plain wrong. The first thing a normal wireguard faces is... the wild network of the Internet, with many servers and hordes of malicious agents. This is what makes is an "encrypted VPN", it's expected to withstand being transmitted by garbage media.
>potential for RCE before packets reach wireguard
There is no such thing as "rce packets". Moreover, every wireguard implementation has a different surface for RCEs (bugs), it's not a property of wireguard, it's a property of the implementation, of which there are at least three.
aborsy 18 hours ago [-]
You didn't get it. It would be more clear if you implement it.
With these wrappers, peers also install and run wrapper and unwrapper services, to encapsulate udp packets into websocket frames and vice versa. For example, the software that proceses incoming packets from the internet could be wstunnel listening on 443/TCP. This layer converts the websocket TCP traffic to wireguard UDP, which wireguard would then decrypt. Wireguard could even listen to local host.
In popular implementations, this layer could have notable attack surface, particularly because it often provides additional features, such as obfuscation behind https, authentication, TLS client certificate validation, etc. I recall Debian has a minimal package which does only UDP to tcp parsing and conversion, which is written in C and not maintained. That layer could be insecure, and may lead to code execution on server before wireguard is even involved.
tptacek 18 hours ago [-]
No, the parent commenter's logic is sounder than yours. WireGuard in its natural configuration can't trust incoming packets at all, so there's nothing to subtract by layering things on top of it.
Obviously, all software creates an opportunity for a bug, so even though this is pretty low-risk as attack surface goes, if you're making a choice between plain natural WireGuard and WireGuard wrapped in WebSockets, the "plain" version has marginally less attack surface.
But if your choice is between WireGuard wrapped in WebSockets or an entire new VPN protocol, clearly the new protocol drastically increases the attack surface.
In any case: wrapping WireGuard with something else does nothing at a design level to put WireGuard's security at risk. That's not how it works.
aborsy 18 hours ago [-]
In your implementation, you wrote software that listens to public internet, takes as input websocket traffic and outputs UDP. Right there, there is potential for vulnerabilities and code execution. This piece has nothing to do with software that would next process UDP.
That's why wireguard over TCP is not as secure as wireguard UDP.
tptacek 18 hours ago [-]
This makes no sense. It's marginally less safe to accept UDP packets than TCP packets, for which you at least need to complete a 3WH to deliver frames. I don't think you've thought this through.
codethief 17 hours ago [-]
IIUC the parent's point is that if you first have to unwrap incoming, say, HTTPS traffic to obtain the Wireguard UDP packets, that unwrapping code might contain vulnerabilities, so an attack compromising the machine Wireguard is running on might occur before the packets ever reach the Wireguard implementation. From where I stand that's a somewhat academic scenario, though. (Unwrapping correctly & safely is usually not that difficult. Just don't use a memory-unsafe language for parsing & unpacking maybe.)
tptacek 17 hours ago [-]
I address that at length 2 comments back.
aboardRat4 13 hours ago [-]
No you did not.
Wrapping-Unwrapping code is irrelevant to the security of wireguard.
Even if your wrapper-unwrapper is an outright remote shell without authorization, it would do nothing to compromise wireguard itself, as long as that shell has no sudo.
But in any case, that wrapper-unwrapper is usually just a packet rewriter, port-to-port, runs as a disabled user with no login privileges, no shell, and in a chroot. The only thing your RCE can do is to exit(1) the rewriter itself.
thadt 18 hours ago [-]
> There is no such thing as "rce packets".
I mean, that depends quite a bit on the code reading the packets, no?
My interpretation of OP is that they trust Wireguard’s code to be secure - random wrappers, somewhat less so.
aboardRat4 13 hours ago [-]
>My interpretation of OP is that they trust Wireguard’s code to be secure - random wrappers, somewhat less so.
There is not such thing as "wireguard code". Wireguard is a protocol, and "the security of wireguard" is the inability of the attackers to read the contents of the stream. This is not affected by the wrapper, because a wrapper is no more hazardous than the high seas, i.e. the Internet.
Speaking of implementation code. There are three wireguard implementations that I am aware of: Go, Linux, and OpenBSD. I am quite sure that none of those are bug-free, but adding a wrapper around wireguard packets has NO effect on the security of the implementation. The implementation is receiving packets from "something". This something can be either the net, or the wrapper, or even /dev/urandom
thadt 11 hours ago [-]
> because a wrapper is no more hazardous than the high seas, i.e. the Internet.
Unless that wrapper is running on the same machine as my Wireguard code - and then the wrapper becomes a potential weak point in the system.
I see where you're coming from and agree with you - in theory, a wrapper is usually thin and shouldn't impact the overall security posture of the system. But this is 2026. AI is regularly curb stomping any notion we had that we write good code and someone just discovered that my SSH server has gone the last decade allowing a login to anyone that pounds out enough 'A' into the password prompt [1].
Given that, I have a fair bit more trust that Jason's Wireguard code (the implementations you mention) correctly handles random packets off the Internet than a wrapper running in the same context.
Trivially, any layer on top very much influences the security. It usually runs on the same server, and in fact is often combined with wireguard code into a new VPN. In fact there are additional layers: firewall code, networking stack code, VPN, rest of OS. Just recently there was a critical vulnerability in Linux kernel TCP connection handling code. It wouldn't matter if OpenVPN listens to TCP connections on the same server: attacker may become root before meeting the VPN.
You can write a bare wapper in few hundreds lines of python, but it won't be robust to resume connections etc. The next step up is something like ProxyGuard referenced in this post, but look at repo to see the size of the code. It's this software that listens to open port, and if it has vulnerabilities, there will be remote code execution on the wireguard server. Then we have more featureful software such as wstunnel that are much bigger.
Most if not all software changes with platform. That's trivial.
I have dealt with this issue for a while.
Update: It seems you acknowledge the issue when you say in another comment "as long as the remote attacker does have sudo privilege". First, remote attacker may get root. Second, even if someone runs as a non root user on the same wireguard server, that's equivalent to that person bypassing the wireguard plus logging in as that user, which is worse. Authenticating to the server is an additional step that they would have to do even if they bypass the VPN.
tptacek 19 hours ago [-]
This isn't true. You don't lose the security properties of WireGuard just because you wrap it in some other transport. There is no particular virtue to it "taking the packets first".
justsomehnguy 18 hours ago [-]
> You want wireguard to be the software that takes the packets first.
Congratulations, DPI marked your connection as... WireGuard and blocked it.
I'd say you are now double safe - there is could be no RCE if there is no packets at all.
nirui 17 hours ago [-]
WireGuard by itself is bare. Currently it don't have a "proper" ("official") way to make custom transport for it. Thus if you have to do it, the task is no different than writing a UDP proxy.
But that UDP proxy is then an independent program, with no awareness on the states of the WireGuard instance, thus the proxy have to run in a very dumb/blind way. That's not ideal.
If you want to write a network proxy, it's the best for the proxy to know as much user intent as possible, so for example it knows which request should be retried, which should be given up as fast as possible if encountered a fault, and which request should just be rerouted to another server, etc.
tptacek 17 hours ago [-]
Why is it best for the proxy to "know as much user intent as possible"? You can get that with WireGuard either way, but it's not at all clear to me that's true. We ran a rather huge deployment of WebSockets-encapsulated WireGuard, and I believe Tailscale has as well, and the fact that WireGuard was oblivious to it caused no problems I'm aware of.
txrx0000 14 hours ago [-]
I think there is value in undisciplined projects like this one because we may find protocols that beat incumbents by pure chance.
WhyNotHugo 20 hours ago [-]
> Not sure why you'd vibe-code a new VPN protocol, double ratchet or otherwise, when you can just take WireGuard and make a new transport for it.
Why TFA explains it, it's also in the title: "stealth". WireGuard is trivial to detect and block, and has no aspirations at being stealth.
ronsor 20 hours ago [-]
He literally acknowledged that:
> WireGuard by itself is not a stealth VPN, but the things that make a VPN "stealthy" are all things you'd layer on top of a WireGuard design, not thread through the middle of it. A datagram-based protocol can run under any obscured transport.
UqWBcuFx6NV4r 19 hours ago [-]
Please read the full comment before replying.
nyeki 19 hours ago [-]
[dead]
tptacek 19 hours ago [-]
And even if you don't tunnel an existing WireGuard implementation (ideally, you would, to inherit the security track record of that implementation) you at least get the design right. Doing a brand new encrypted transport design for no good reason is a weird red flag for me.
Sha1rholder 20 hours ago [-]
> Memory-safe in Rust
> The core is written in Rust, so entire classes of vulnerability cannot occur.
There's this naive view of security where you can just 'add' security to something like you are applying some medicine. You add rust to software to increase security, you install antiviruses to computers to make them more secure..
I discovered recently Three UK is slowing down port 443, and if I started using 2000-3000 port range it increased my speeds 10x
rock_artist 19 hours ago [-]
> The mobile apps are paid. Development is fully funded by PDG Global Limited; revenue from app sales, together with donations, contributes towards development costs. The core remains open source under AGPLv3.
lifeisloving 19 hours ago [-]
I cant find anything on this company, but I got to say im sussed out by any VPN who's three language options are English, Russian and Chinese. It screams spook activity.
aboardRat4 19 hours ago [-]
>im sussed out by any VPN who's three language options are English, Russian and Chinese. It screams spook activity.
Not at all. China, Russia, and Iran are the three biggest markets for VPNs.
In China about 150 million people use a VPN, in Russia about 60 million, about half the population
petu 19 hours ago [-]
Throw in Iran/Farsi and you've probably covered >80% of the stealth VPN market/users. Normal protocols get blocked in those countries, so.
Sha1rholder 18 hours ago [-]
On the contrary! The main market for this type of VPN is China, Russia, and Iran.
lifeisloving 17 hours ago [-]
Sure, but why do you think they're marketed these services, who would it be valuable too...
Most VPN companies are incredibly sus, outside of Mulvad they're mostly all incredibly suspicious imo. Western intelligence is desperate to enable the use of such tools in enemy territory so they can bombard enemy culture with American culture and make the populations eager to adopt American/Western customs and as a byproduct install leaders who are pro western ideology and less likely to be adversarial. VPNs when marketed to these countries should be seen as tools of propaganda dissemination l, in my opinion.
The EFF will talk a big game about how this tech is about freedom of information, human rights and democracy.but really they're founded by a bunch of US Naval Research guys who are basically tasked with building the "cyber" infrastructure to ideologically invade adversial countries so they can be psychologically colonized. They then launder that mission with discussions about free speech and democracy.
The original US Army's Psychological Operations Unit, was called the "Ghost Army" they used a patch with a ghost hovering over an implied target shooting electricity from its hands.
The ghost on the patch is symbolic for beaming in signals into enemy territory to brainwash, intimidate and control an enemy population.
The reason that China, Russia and Iran have nation state firewalls is because the US is so good at this, and the US wants to control any country who has any potential of competing with it. Its not because they hate freedom or something, its because anyone the US has deemed an economic or ideological opponent will be targeted in this way. We will beam signals through whatever means/protocol into a country to gain a psychological foothold in their culture, we will then convince them to kill their leaders and install US puppets.
I routinely say that Starlink should make its logo the Ghost Army patch, because thats what it was built for. While it functions as a cool business, and does provide value, it was created as the ultimate propaganda dissemination tool
(eventually atleast, it will be very hard to mitigate against if they can pull off some sort of cellular implementation of Starlink, which they're actively working towards).
TOR and VPN companies attempted to serve this purpose, when this paradigm failed to be a general purpose tool for bypassing nation state firewalls they had to find another way so they helped Elon bootstrap a literal satallite constellation for this purpose. Its literally the Ghost in the sky waving its hand over a population with few ways to prevent its use.
The VPN industry in China, Russia and Iran are weapons for this agenda.
firen777 15 hours ago [-]
> The original US Army's Psychological Operations Unit, was called the "Ghost Army" they used a patch with a ghost hovering over an implied target shooting electricity from its hands.
> The ghost on the patch is symbolic for beaming in signals into enemy territory to brainwash, intimidate and control an enemy population.
> The Ghost Army was a United States Army tactical deception unit during World War II officially known as the 23rd Headquarters Special Troops. The 1,100-man unit was created to deceive the Axis forces and mislead them as to the size and location of Allied forces, while giving the actual units elsewhere time to maneuver.
> ... During their tenure, the Ghost Army carried out more than 20 deception campaigns, putting on a "traveling road show" using inflatable tanks, sound trucks, fake radio transmissions, scripts and pretense.
Also the description on the patch:
> Ghost Army insignia, not used by the actual unit, but associated with the unit after the war
gruez 19 hours ago [-]
>It screams spook activity.
Like, it's a FBI honeypot or it's a CIA op to help dissidents?
lifeisloving 4 hours ago [-]
Push western news narratives, propaganda, help dissidents/traitors. Cultural colonization.
eric15342335 20 hours ago [-]
Why not Xray-core VLESS families?
It sounds like your code is written by an LLM that is trained on Xray-core source code.
f311a 19 hours ago [-]
It’s not enough to put everything in https if you really want to circumvent modern censorship technology.
hrunt 14 hours ago [-]
This. Modern censorship technology (and not US ISP censorship, but state-level censorship like China and Iran use) are very adept at looking at traffic patterns and within a few seconds, determining that traffic on HTTPS ports is not actually HTTPS traffic. HTTPS traffic has certain behaviors that are not replicated by VPN flows.
20 hours ago [-]
jmclnx 20 hours ago [-]
>stealth VPN with end-to-end encryption
Not sure what this means. AFAIK all VPNs have end-to-end encryption. Stealth ? will need to read to see what that means.
TZubiri 18 hours ago [-]
I read that as destination hosts being unable to distinguish a VPN user from a regular user.
The typical use case for this is usually malicious btw, and the means to do this are residential proxies, which again are usually maliciously obtained
tonymet 20 hours ago [-]
a vpn that bypasses deep-packet-inspection firewalls by simulating common HTTPS traffic
dieseltech 21 hours ago [-]
> We believe privacy should be proven, not promised
Then instantly gives you a shell script that it pipes to `sudo bash`. The irony isn't lost here.
hirako2000 20 hours ago [-]
That's also the cost of providing convenience AND something that can open port 443
denkmoon 17 hours ago [-]
Convenient for the author, sure. Most operating systems have a way of installing packages as the administrative user without piping random scripts from the internet into sudo bash, I suspect most users already know and may even like their operating system's method for installing software.
Carrok 21 hours ago [-]
Also the suggested installation method of at least: rust, bun, uv, deno, and homebrew
Just because everyone else is doing it doesn't mean it's right.
Carrok 3 hours ago [-]
Just because some people take issue with it doesn't mean it's wrong.
TZubiri 18 hours ago [-]
>Such a tired trope.
Criticism doesn't expire or saturate, if something is wrong, and people continue to do it, it's still wrong thereafter
breakwaterlabs 18 hours ago [-]
It is possible to write a TLS-on-443 VPN that is hard to distinguish from HTTPS.
However, if someone claims (or as good as) that "encrypted over TLS on 443" intrinsically pos5esses this property, they demonstrate that they
• do not understand the state-of-the-art in L7 firewalls as of 2010, let alone today
• don't understand common enterprise and state-level controls like HTTPS decrypt (which instantly break this)
• haven't read any of the last decade of papers on detecting protocols like obfsproxy
• haven't even bothered to look at existing takes on this (like tor) and the compromises that they make
---
From the whitepaper:
> Desktop, CLI, and Android clients use BoringSSL to mimic a Chrome TLS 1.3 ClientHello fingerprint, helping evade deep-packet inspection.
Do you set an SNI / eSNI? No? Trivially detectable. I believe Palo Alto AppID would flag this instantly as non-HTTPS masqueraded traffic.
Go fire this up behind China's golden shield, and see how many minutes your tunnel stays performant before they tarpit you; then come write a whitepaper.
txrx0000 14 hours ago [-]
You understand this area better than I do, so enlighten me if you will. I think this race will end with detectors running models vs evaders running models, then evaders lose because detectors have more compute.
Unless evaders share information with eachother in realtime - probably something like Yggdrasil network, and then everyone needs to let some of their unimportant traffic go unwrapped so that each node can run a local continually finetuned model to maintain a living spec which describes how to mimic the clear traffic on that node, then trade those specs with eachother.
kevin_b_er 16 hours ago [-]
Appears to be a websocket tunnel delivered after regular HTTPS. So, probably an SNI. In general, its wstunnel.
breakwaterlabs 14 hours ago [-]
It is somewhat irrelevant. There were papers 12 years ago on detecting things like obfsproxy (and its ilk) by traffic pattern analysis. It is extremely difficult to make a traffic tunnel look like standard web traffic and not like a tunnel.
And because the idea is rather obvious-- one of OpenVPN's original raison d'etres, decades ago, was evading detection-- L7 firewalls for corporate and state customers have been rather keen to shore up their detections for all manner of meek, snowflake, obfsproxy, and obscure VPNs.
My understanding as of a decade ago was that China's golden shield, on seeing mysterious multiminute encrypted "HTTPS" sessions, tarpit it and attempt scans / DOS attacks on the other end. How's your rVPN going to hold up when baidu LOICs your endpoint?
forgotpwd16 9 hours ago [-]
>Go fire this up behind China's golden shield, and see how many minutes your tunnel stays performant before they tarpit you; then come write a whitepaper.
Claude told them it's fine so should be ok, right? /s
lxgr 20 hours ago [-]
> curl https://[...] | sudo bash
> [...] verifies checksum [...]
Phew, good thing it verifies that, otherwise piping unverified output to a sudo shell could be dangerous!
PUSH_AX 21 hours ago [-]
There's only 4 mentions of Rust on the landing page. Are we sure this is memory safe enough?
cowlevel 20 hours ago [-]
To be extra sure I saved a copy on a spinning platter of iron oxide.
therein 20 hours ago [-]
I am all for exciting new VPN technologies but even the home page is vibecoded.
> Many flows. One connection shape
Shape, shape... shape.
I feel up until AI, nobody with their right mind would refer to the shape of a connection.
cowlevel 20 hours ago [-]
That's how you know there's nothing exciting here. Just some ordinary technology rehyped by AI phrasing.
therein 20 hours ago [-]
Yeah. Sounds like just wstunnel would be equivalent in many ways.
Do you have a Docker image available? I want to run this on my Coolify server. I have a V2Ray for my family in Iran setup currently and I am wondering how this hold up.
BatchJob 15 hours ago [-]
When I see stuff like this at first I think oh something I can use, and then the next thought is, wait is this to make it easier for bots to hammer the web undetected?
Yes I think its really just the latter.
tonymet 20 hours ago [-]
i was needing this very thing while trying to do work from the infusion clinic with a very aggressive outbound firewall.
Does anyone have a guide on getting wireguard + stunnel set up to evade DPS firewalls?
WireGuard by itself is not a stealth VPN, but the things that make a VPN "stealthy" are all things you'd layer on top of a WireGuard design, not thread through the middle of it. A datagram-based protocol can run under any obscured transport.
We did this at Fly.io when we discovered that, for one reason or another, 5% of our users simply couldn't reliably use UDP. It was a one-day project to run it under WebSockets instead, and that was before coding agents.
The parent is obviously just Claude making a fancy website and some sort of unreviewed networking protocol that's dressed up to look as if it's a real project. Github really needs to start showing commit cadence and repo birthdates.
netbird's a thing to check out if you want an alternative to tailscale you can self-host.
I contributed some features to it and switched
You want wireguard to be the software that takes the packets first.
That's plain wrong. The first thing a normal wireguard faces is... the wild network of the Internet, with many servers and hordes of malicious agents. This is what makes is an "encrypted VPN", it's expected to withstand being transmitted by garbage media.
>potential for RCE before packets reach wireguard
There is no such thing as "rce packets". Moreover, every wireguard implementation has a different surface for RCEs (bugs), it's not a property of wireguard, it's a property of the implementation, of which there are at least three.
With these wrappers, peers also install and run wrapper and unwrapper services, to encapsulate udp packets into websocket frames and vice versa. For example, the software that proceses incoming packets from the internet could be wstunnel listening on 443/TCP. This layer converts the websocket TCP traffic to wireguard UDP, which wireguard would then decrypt. Wireguard could even listen to local host.
In popular implementations, this layer could have notable attack surface, particularly because it often provides additional features, such as obfuscation behind https, authentication, TLS client certificate validation, etc. I recall Debian has a minimal package which does only UDP to tcp parsing and conversion, which is written in C and not maintained. That layer could be insecure, and may lead to code execution on server before wireguard is even involved.
Obviously, all software creates an opportunity for a bug, so even though this is pretty low-risk as attack surface goes, if you're making a choice between plain natural WireGuard and WireGuard wrapped in WebSockets, the "plain" version has marginally less attack surface.
But if your choice is between WireGuard wrapped in WebSockets or an entire new VPN protocol, clearly the new protocol drastically increases the attack surface.
In any case: wrapping WireGuard with something else does nothing at a design level to put WireGuard's security at risk. That's not how it works.
That's why wireguard over TCP is not as secure as wireguard UDP.
Wrapping-Unwrapping code is irrelevant to the security of wireguard. Even if your wrapper-unwrapper is an outright remote shell without authorization, it would do nothing to compromise wireguard itself, as long as that shell has no sudo.
But in any case, that wrapper-unwrapper is usually just a packet rewriter, port-to-port, runs as a disabled user with no login privileges, no shell, and in a chroot. The only thing your RCE can do is to exit(1) the rewriter itself.
I mean, that depends quite a bit on the code reading the packets, no?
My interpretation of OP is that they trust Wireguard’s code to be secure - random wrappers, somewhat less so.
There is not such thing as "wireguard code". Wireguard is a protocol, and "the security of wireguard" is the inability of the attackers to read the contents of the stream. This is not affected by the wrapper, because a wrapper is no more hazardous than the high seas, i.e. the Internet.
Speaking of implementation code. There are three wireguard implementations that I am aware of: Go, Linux, and OpenBSD. I am quite sure that none of those are bug-free, but adding a wrapper around wireguard packets has NO effect on the security of the implementation. The implementation is receiving packets from "something". This something can be either the net, or the wrapper, or even /dev/urandom
Unless that wrapper is running on the same machine as my Wireguard code - and then the wrapper becomes a potential weak point in the system.
I see where you're coming from and agree with you - in theory, a wrapper is usually thin and shouldn't impact the overall security posture of the system. But this is 2026. AI is regularly curb stomping any notion we had that we write good code and someone just discovered that my SSH server has gone the last decade allowing a login to anyone that pounds out enough 'A' into the password prompt [1].
Given that, I have a fair bit more trust that Jason's Wireguard code (the implementations you mention) correctly handles random packets off the Internet than a wrapper running in the same context.
[1] https://news.ycombinator.com/item?id=50378228
You can write a bare wapper in few hundreds lines of python, but it won't be robust to resume connections etc. The next step up is something like ProxyGuard referenced in this post, but look at repo to see the size of the code. It's this software that listens to open port, and if it has vulnerabilities, there will be remote code execution on the wireguard server. Then we have more featureful software such as wstunnel that are much bigger.
Most if not all software changes with platform. That's trivial.
I have dealt with this issue for a while.
Update: It seems you acknowledge the issue when you say in another comment "as long as the remote attacker does have sudo privilege". First, remote attacker may get root. Second, even if someone runs as a non root user on the same wireguard server, that's equivalent to that person bypassing the wireguard plus logging in as that user, which is worse. Authenticating to the server is an additional step that they would have to do even if they bypass the VPN.
Congratulations, DPI marked your connection as... WireGuard and blocked it.
I'd say you are now double safe - there is could be no RCE if there is no packets at all.
But that UDP proxy is then an independent program, with no awareness on the states of the WireGuard instance, thus the proxy have to run in a very dumb/blind way. That's not ideal.
If you want to write a network proxy, it's the best for the proxy to know as much user intent as possible, so for example it knows which request should be retried, which should be given up as fast as possible if encountered a fault, and which request should just be rerouted to another server, etc.
Why TFA explains it, it's also in the title: "stealth". WireGuard is trivial to detect and block, and has no aspirations at being stealth.
> WireGuard by itself is not a stealth VPN, but the things that make a VPN "stealthy" are all things you'd layer on top of a WireGuard design, not thread through the middle of it. A datagram-based protocol can run under any obscured transport.
Hmm... It just ain't true.
---
For those who need a "stealth VPN", use <https://github.com/XTLS/Xray-core/> or its GUI version <https://github.com/2dust/v2rayN/>
Not at all. China, Russia, and Iran are the three biggest markets for VPNs.
In China about 150 million people use a VPN, in Russia about 60 million, about half the population
Most VPN companies are incredibly sus, outside of Mulvad they're mostly all incredibly suspicious imo. Western intelligence is desperate to enable the use of such tools in enemy territory so they can bombard enemy culture with American culture and make the populations eager to adopt American/Western customs and as a byproduct install leaders who are pro western ideology and less likely to be adversarial. VPNs when marketed to these countries should be seen as tools of propaganda dissemination l, in my opinion.
The EFF will talk a big game about how this tech is about freedom of information, human rights and democracy.but really they're founded by a bunch of US Naval Research guys who are basically tasked with building the "cyber" infrastructure to ideologically invade adversial countries so they can be psychologically colonized. They then launder that mission with discussions about free speech and democracy.
The original US Army's Psychological Operations Unit, was called the "Ghost Army" they used a patch with a ghost hovering over an implied target shooting electricity from its hands.
https://upload.wikimedia.org/wikipedia/commons/7/75/Ghostarm...
The ghost on the patch is symbolic for beaming in signals into enemy territory to brainwash, intimidate and control an enemy population.
The reason that China, Russia and Iran have nation state firewalls is because the US is so good at this, and the US wants to control any country who has any potential of competing with it. Its not because they hate freedom or something, its because anyone the US has deemed an economic or ideological opponent will be targeted in this way. We will beam signals through whatever means/protocol into a country to gain a psychological foothold in their culture, we will then convince them to kill their leaders and install US puppets.
I routinely say that Starlink should make its logo the Ghost Army patch, because thats what it was built for. While it functions as a cool business, and does provide value, it was created as the ultimate propaganda dissemination tool
(eventually atleast, it will be very hard to mitigate against if they can pull off some sort of cellular implementation of Starlink, which they're actively working towards).
TOR and VPN companies attempted to serve this purpose, when this paradigm failed to be a general purpose tool for bypassing nation state firewalls they had to find another way so they helped Elon bootstrap a literal satallite constellation for this purpose. Its literally the Ghost in the sky waving its hand over a population with few ways to prevent its use.
The VPN industry in China, Russia and Iran are weapons for this agenda.
> The ghost on the patch is symbolic for beaming in signals into enemy territory to brainwash, intimidate and control an enemy population.
Any source that support your claims?
From wikipedia (https://en.wikipedia.org/wiki/Ghost_Army):
> The Ghost Army was a United States Army tactical deception unit during World War II officially known as the 23rd Headquarters Special Troops. The 1,100-man unit was created to deceive the Axis forces and mislead them as to the size and location of Allied forces, while giving the actual units elsewhere time to maneuver.
> ... During their tenure, the Ghost Army carried out more than 20 deception campaigns, putting on a "traveling road show" using inflatable tanks, sound trucks, fake radio transmissions, scripts and pretense.
Also the description on the patch:
> Ghost Army insignia, not used by the actual unit, but associated with the unit after the war
Like, it's a FBI honeypot or it's a CIA op to help dissidents?
Not sure what this means. AFAIK all VPNs have end-to-end encryption. Stealth ? will need to read to see what that means.
The typical use case for this is usually malicious btw, and the means to do this are residential proxies, which again are usually maliciously obtained
Then instantly gives you a shell script that it pipes to `sudo bash`. The irony isn't lost here.
Such a tired trope. If you want to do it the hard way, you are welcome to build by hand https://github.com/PDG-Global/rVPN-core#building
Criticism doesn't expire or saturate, if something is wrong, and people continue to do it, it's still wrong thereafter
However, if someone claims (or as good as) that "encrypted over TLS on 443" intrinsically pos5esses this property, they demonstrate that they
• do not understand the state-of-the-art in L7 firewalls as of 2010, let alone today
• don't understand common enterprise and state-level controls like HTTPS decrypt (which instantly break this)
• haven't read any of the last decade of papers on detecting protocols like obfsproxy
• haven't even bothered to look at existing takes on this (like tor) and the compromises that they make
---
From the whitepaper:
> Desktop, CLI, and Android clients use BoringSSL to mimic a Chrome TLS 1.3 ClientHello fingerprint, helping evade deep-packet inspection.
Do you set an SNI / eSNI? No? Trivially detectable. I believe Palo Alto AppID would flag this instantly as non-HTTPS masqueraded traffic.
Go fire this up behind China's golden shield, and see how many minutes your tunnel stays performant before they tarpit you; then come write a whitepaper.
Unless evaders share information with eachother in realtime - probably something like Yggdrasil network, and then everyone needs to let some of their unimportant traffic go unwrapped so that each node can run a local continually finetuned model to maintain a living spec which describes how to mimic the clear traffic on that node, then trade those specs with eachother.
And because the idea is rather obvious-- one of OpenVPN's original raison d'etres, decades ago, was evading detection-- L7 firewalls for corporate and state customers have been rather keen to shore up their detections for all manner of meek, snowflake, obfsproxy, and obscure VPNs.
My understanding as of a decade ago was that China's golden shield, on seeing mysterious multiminute encrypted "HTTPS" sessions, tarpit it and attempt scans / DOS attacks on the other end. How's your rVPN going to hold up when baidu LOICs your endpoint?
Claude told them it's fine so should be ok, right? /s
> [...] verifies checksum [...]
Phew, good thing it verifies that, otherwise piping unverified output to a sudo shell could be dangerous!
> Many flows. One connection shape
Shape, shape... shape.
I feel up until AI, nobody with their right mind would refer to the shape of a connection.
https://github.com/erebe/wstunnel
Yes I think its really just the latter.
Does anyone have a guide on getting wireguard + stunnel set up to evade DPS firewalls?