Re: WireGuard with obfuscation support

[StarBrilliant <coder@poorlab.com>]

On Mon, Sep 27, 2021, at 15:59, Nico Schottelius wrote:
> 
> StarBrilliant <coder@poorlab.com> writes:
> 
> > On Mon, Sep 27, 2021, at 10:21, Bruno Wolff III wrote:
> >> If your ISP is blocking your Wireguard traffic call them up and complain.
> >
> > All ISPs in China is blocking Wireguard traffic. If you call any of
> > them up, you will end up in jail. There was a case where one user sued
> > their ISP for blocking Google, and got prosecuted until disappear in
> > public.
> > [...]
> 
> I'm not sure how much wireguard depends on the IP/UDP layers, but
> assuming it only uses it for payload, maybe it makes sense to
> wrap wireguard into HTTP, HTTPS, SMTP (+TLS), IMAP(S) or even DNS
> (slow). I am aware that there is a variety of tools out there that
> handle some of the tunnel ideas.
> 
> Given that all of these approaches are actually rather trivial to
> implement, is there any easy way to grab the outgoing wireguard packets
> without the need of creating n artifical local UDP endpoints?
> 

For your first question: There have been multiple success stories for pluggable obfuscation layers: One from Tor Project, another from V2Ray. They proved even if any single obfuscation is not mature, as long as new obfuscation plugins emerge way way faster than their statistical model training speed, this cat-and-mouse game can win. So no worries about this question.

For the second question: This is very important because current Wireguard has huge pain with obfuscation plugins.
* Firstly, Wireguard cannot bind to localhost only. Using iptables to restrict access does not avoid port number wasting.
* Second, Wireguard can't use Unix socket for transport -- there are only 65535 UDP ports, it is not economic to waste a dozen of them just for connecting to an obfuscation plugin located at localhost.
* Last but not least, Wireguard relies on certain end-to-end features: If the a fragmented IP packet arrives, which is a feature that some obfuscation plugin relies on, Wireguard's kernel implementation will behave strangely. Also Wireguard needs to know the endpoint IP address to perform roaming.

Previously we prefer to patch the Go version because the above three issues are almost impossible to solve in kernel space. But the Wireguard upstream is going to deprecate the Go version on Linux platforms, which would not be a good news for the obfuscation world.

If Wireguard supports listening onto a Unix socket and plugin protocols like “HAProxy protocol”, or “Tor FTE protocol” or “Shadowsocks SIP003 protocol” (not sure which can work with UDP), then obfuscation plugins can happily work with Wireguard.