>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 a day 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. 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 a day 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 a day 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 a day 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 a day 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.)

▲

tptacek a day ago | parent [-]

I address that at length 2 comments back.

	▲	aboardRat4 21 hours ago \| parent [-]
		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 a day 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.

▲

aboardRat4 21 hours ago | parent [-]

>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 19 hours ago \| parent \| next [-]
		> 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. [1] https://news.ycombinator.com/item?id=50378228
	▲	aborsy 17 hours ago \| parent \| prev [-]
		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.