logoalt Hacker News

aboardRat4 • yesterday at 11:53 PM • 2 replies • view on HN

>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.


Replies

aborsy • today at 12:18 AM

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.

➕ show 1 reply
thadt • today at 12:12 AM

> 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.