| ▲ | tptacek 3 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 3 hours ago | parent | next [-] |
| 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 3 hours ago | parent | next [-] | | > 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 3 hours ago | parent | next [-] | | 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. | | | |
| ▲ | tamimio 2 hours ago | parent | prev [-] | | 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. |
| |
| ▲ | tamimio 2 hours ago | parent | prev [-] | | Which is why I am building my stuff around iroh instead. |
|
|
| ▲ | nirui 26 minutes ago | parent | prev | next [-] |
| 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 8 minutes ago | parent [-] | | Why is it best for the proxy to "know as much user intent as possible"? You can ge 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. |
|
|
| ▲ | aborsy 2 hours ago | parent | prev | next [-] |
| 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 2 hours ago | parent | next [-] | | >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 an hour ago | parent | next [-] | | 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. Debian seems to have a minimal package, which is written in C. That layer could be insecure, and may lead to code execution on server before wireguard is even involved. | | |
| ▲ | tptacek an hour ago | parent [-] | | 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 an hour ago | parent [-] | | 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 an hour ago | parent [-] | | 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 minutes ago | parent [-] | | 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.) | | |
|
|
|
| |
| ▲ | thadt an hour ago | parent | prev [-] | | > 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. |
| |
| ▲ | tptacek 2 hours ago | parent | prev | next [-] | | 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 an hour ago | parent | prev [-] | | > 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. |
|
|
| ▲ | nyeki 2 hours ago | parent | prev | next [-] |
| Yeah, I just forwarded my wireguard connection through websockets with this and even though it's way slower it works just fine. Not even 1000 loc i think. https://github.com/nekidev/tow |
| |
| ▲ | tptacek 2 hours ago | parent [-] | | 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. |
|
|
| ▲ | WhyNotHugo 3 hours ago | parent | prev [-] |
| > 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 3 hours ago | parent | next [-] | | 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 2 hours ago | parent | prev [-] | | Please read the full comment before replying. |
|
