WireGuard with obfuscation support
rm at romanrm.net
Mon Sep 27 07:34:39 UTC 2021
On Mon, 27 Sep 2021 02:11:30 -0500
Bruno Wolff III <bruno at wolff.to> wrote:
> On Mon, Sep 27, 2021 at 09:53:08 +0900,
> Nico Schottelius <nico.schottelius at ungleich.ch> wrote:
> >I'd appreciate if wireguard upstream would take this in, maybe even
> >supporting multiple / dynamic listen ports.
> The problem is mostly orthogonal to Wireguard. There isn't going to be a
> one size fits all solution for hiding traffic. Failures in hiding traffic
> are potentially very bad for individuals. As such general solutions are
> not something you can recommend universally to people, as amateurs are
> not going to be able to make good decisions about the risks and some may
> get themselves tortured and killed.
> This may not be something the developers for Wireguard want to be
> responsible for.
No need to make DPI's job especially easy either.
Don't over-estimate the resources available to DPIs, if there aren't easy
ways to block, it might be almost as good as unblockable.
And it is far from all cases that hiding traffic would result in bad
consequences. Just hiding it enough so it evades the dumb automated filter,
many people will thank you.
As far as I understand right now WireGuard is very vulnerable to being
blocked, due to the fixed 4 bytes at the beginning(?) of each packet. At least
that needs to be randomized/encrypted. Just make the entire packet look like
random noise - that's the sign of good crypto, right? It is even somewhat
surprising as to why that's not the case already.
More information about the WireGuard