alt Hacker NewsYou 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.
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.