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 2 hours 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 2 hours 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 2 hours 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 2 hours 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 an hour ago \| parent [-]
		I address that at length 2 comments back.