Development discussion of WireGuard
 help / color / mirror / Atom feed
* WireGuard with obfuscation support
@ 2021-09-26 12:09 el3xyz
  2021-09-27  0:53 ` Nico Schottelius
  2021-09-27 16:21 ` Jason A. Donenfeld
  0 siblings, 2 replies; 15+ messages in thread
From: el3xyz @ 2021-09-26 12:09 UTC (permalink / raw)
  To: wireguard

Hey all,

I guess this topic is, at the very least, not new, but there is still no solution. In the country where I live internet censorship increases year after year and more network operators start blocking WG. With that being done I'm stuck to ShadowSocks which is slower and less secure on desktops then WG. That said I decided to implement obfuscation for WG at least for my own use and kindly asking for code review and possible improvements:

https://github.com/el3xyz/wireguard-linux-compat

To my understanding there are several ways WG is detected by DPI
* Port 51820 (easily fixed)
* 4-byte message tag
* Fixed message lengths
* MAC2 which is all zeroes, unless cookie message is received (high load scenario)


To make detection more difficult two things are being done
* handshake initiation, response and cookie messages are padded with random sized garbage
* Up to 192 bytes of each message is encrypted with obfuscation key derived from peer public key (different keys are used in different directions).

I have tools and Linux driver working already so anyone interested can try this out.
Cheers

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: WireGuard with obfuscation support
  2021-09-26 12:09 WireGuard with obfuscation support el3xyz
@ 2021-09-27  0:53 ` Nico Schottelius
  2021-09-27  7:11   ` Bruno Wolff III
  2021-09-27 16:21 ` Jason A. Donenfeld
  1 sibling, 1 reply; 15+ messages in thread
From: Nico Schottelius @ 2021-09-27  0:53 UTC (permalink / raw)
  To: el3xyz; +Cc: wireguard


Hey,

el3xyz <el3xyz@protonmail.com> writes:
> [...]
> To make detection more difficult two things are being done
> * handshake initiation, response and cookie messages are padded with random sized garbage
> * Up to 192 bytes of each message is encrypted with obfuscation key derived from peer public key (different keys are used in different directions).
> [...]

I did not have a look at the code itself, but travelling around the
world, I appreciate the direction a lot. While from a safety perspective
this does not anything, it can add a lot to the usability / being able
to use wireguard at all.

I'd appreciate if wireguard upstream would take this in, maybe even
supporting multiple / dynamic listen ports.

Best regards,

Nico



--
Sustainable and modern Infrastructures by ungleich.ch

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: WireGuard with obfuscation support
  2021-09-27  0:53 ` Nico Schottelius
@ 2021-09-27  7:11   ` Bruno Wolff III
  2021-09-27  7:34     ` Roman Mamedov
  2021-09-27  7:44     ` Nico Schottelius
  0 siblings, 2 replies; 15+ messages in thread
From: Bruno Wolff III @ 2021-09-27  7:11 UTC (permalink / raw)
  To: Nico Schottelius; +Cc: el3xyz, wireguard

On Mon, Sep 27, 2021 at 09:53:08 +0900,
  Nico Schottelius <nico.schottelius@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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: WireGuard with obfuscation support
  2021-09-27  7:11   ` Bruno Wolff III
@ 2021-09-27  7:34     ` Roman Mamedov
  2021-09-27  9:14       ` Bruno Wolff III
  2021-09-27  7:44     ` Nico Schottelius
  1 sibling, 1 reply; 15+ messages in thread
From: Roman Mamedov @ 2021-09-27  7:34 UTC (permalink / raw)
  To: Bruno Wolff III; +Cc: Nico Schottelius, el3xyz, wireguard

On Mon, 27 Sep 2021 02:11:30 -0500
Bruno Wolff III <bruno@wolff.to> wrote:

> On Mon, Sep 27, 2021 at 09:53:08 +0900,
>   Nico Schottelius <nico.schottelius@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.

-- 
With respect,
Roman

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: WireGuard with obfuscation support
  2021-09-27  7:11   ` Bruno Wolff III
  2021-09-27  7:34     ` Roman Mamedov
@ 2021-09-27  7:44     ` Nico Schottelius
  2021-09-27  8:17       ` Fredrik Strömberg
  1 sibling, 1 reply; 15+ messages in thread
From: Nico Schottelius @ 2021-09-27  7:44 UTC (permalink / raw)
  To: Bruno Wolff III; +Cc: Nico Schottelius, el3xyz, wireguard


Bruno,

thanks for raising 2 very important points:

Bruno Wolff III <bruno@wolff.to> writes:

> On Mon, Sep 27, 2021 at 09:53:08 +0900,
>  Nico Schottelius <nico.schottelius@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.

1) being able to communicate for non-tech savvy users

This is a very important point, especially a failure to do so might be
critical in reality like you pointed out. So the easier we make it for
non-tech people to "just get it working", many more life's will be saved
from torture. Because the alternative are insecure communication channels.

> This may not be something the developers for Wireguard want to be
> responsible for.

2) The responsibility of software developers

As usual with GPL/similar licenses, software is provided AS-IS. We are
not selling a "fully autonomous car" here that is actually not able to
drive on its own, but instead giving a warranty free software to people.

It's important to raise these points, but from what I can see the easier
we make it for people to securely communicate, the less likely threats
arrive.

Outside of the scope of wireguard I see tunnel combinations like moving
wireguard traffic through udp+tcp/53, tcp/80+443, which are also
interesting options, but are probably solved with other tunneling tools.

Cheers,

Nico

--
Sustainable and modern Infrastructures by ungleich.ch

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: WireGuard with obfuscation support
  2021-09-27  7:44     ` Nico Schottelius
@ 2021-09-27  8:17       ` Fredrik Strömberg
  0 siblings, 0 replies; 15+ messages in thread
From: Fredrik Strömberg @ 2021-09-27  8:17 UTC (permalink / raw)
  To: WireGuard mailing list

Hi everyone,

On Mon, Sep 27, 2021 at 9:55 AM Nico Schottelius
<nico.schottelius@ungleich.ch> wrote:
> Bruno Wolff III <bruno@wolff.to> writes:
> > On Mon, Sep 27, 2021 at 09:53:08 +0900,
> >  Nico Schottelius <nico.schottelius@ungleich.ch> wrote:
> >
> > The problem is mostly orthogonal to Wireguard. There isn't going to be
> > a one size fits all solution for hiding traffic.

Exactly. And it would be a big mistake to attempt to merge obfuscation
support into WireGuard itself. Tor's approach of pluggable transports
is probably the right one.

https://www.wireguard.com/known-limitations/
"WireGuard does not focus on obfuscation. Obfuscation, rather, should
happen at a layer above WireGuard, with WireGuard focused on providing
solid crypto with a simple implementation. It is quite possible to
plug in various forms of obfuscation, however."

Here are my arguments:
https://lists.zx2c4.com/pipermail/wireguard/2018-September/003292.html

Cheers,
Fredrik Stromberg

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: WireGuard with obfuscation support
  2021-09-27  7:34     ` Roman Mamedov
@ 2021-09-27  9:14       ` Bruno Wolff III
  2021-09-27  9:36         ` Roman Mamedov
  0 siblings, 1 reply; 15+ messages in thread
From: Bruno Wolff III @ 2021-09-27  9:14 UTC (permalink / raw)
  To: Roman Mamedov; +Cc: Nico Schottelius, el3xyz, wireguard

On Mon, Sep 27, 2021 at 12:34:39 +0500,
  Roman Mamedov <rm@romanrm.net> wrote:
>On Mon, 27 Sep 2021 02:11:30 -0500
>
>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.

If someone is having their Wireguard traffic blogged, there is a good 
chance that they will be negative consequences to trying to evade the 
block. Just getting detected will often be enough to trigger these 
consequences, even if the traffic is getting through.

This isn't a simple problem. The assumption is that someone is seeing 
your network traffic and blocking it. They are still going to see it 
even if you disguise it. So you are going to need to disquise it as 
something that whoever is watching isn't going to care about. That 
is going to vary a lot depending on who is watching. You may also need 
to hide who you are communicating with. In some cases that will be even 
more important.

There are going to be a number of ways to detect Wireguard traffic and 
it is pretty unlikely that the bar for detection can be raised enough to 
be relevant with a few simple changes to the protocol.

This suggest that Wireguard is not the correct place to be doing these 
things. As suggested in another followup, this fits a lot closer to 
tor's mission and that would probably be a better place to look for 
help.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: WireGuard with obfuscation support
  2021-09-27  9:14       ` Bruno Wolff III
@ 2021-09-27  9:36         ` Roman Mamedov
  2021-09-27 10:21           ` Bruno Wolff III
  0 siblings, 1 reply; 15+ messages in thread
From: Roman Mamedov @ 2021-09-27  9:36 UTC (permalink / raw)
  To: Bruno Wolff III; +Cc: Nico Schottelius, el3xyz, wireguard

On Mon, 27 Sep 2021 04:14:35 -0500
Bruno Wolff III <bruno@wolff.to> wrote:

> This isn't a simple problem. The assumption is that someone is seeing 
> your network traffic and blocking it.

The assumption is that there's an appliance at the ISP which has a DROP rule
for UDP with 4 fixed bytes at a fixed offset. It has five hundreds other rules
to process as well, so it can't spend "too much" time on specifically WG.

> They are still going to see it  even if you disguise it.

With obfuscation there would be UDP packets of random junk, and it would be a
much harder job to come up with a rule to drop those without affecting
anything else.

> So you are going to need to disquise it as  something that whoever is
> watching isn't going to care about. That is going to vary a lot depending on
> who is watching. You may also need to hide who you are communicating with.
> In some cases that will be even more important.

You are going full-on "Enemy of the state" movie. The reality is most often a
lot simpler and more benign.

> There are going to be a number of ways to detect Wireguard traffic and 
> it is pretty unlikely that the bar for detection can be raised enough to 
> be relevant with a few simple changes to the protocol.

That's not a justification for not trying at all.

-- 
With respect,
Roman

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: WireGuard with obfuscation support
  2021-09-27  9:36         ` Roman Mamedov
@ 2021-09-27 10:21           ` Bruno Wolff III
  2021-09-27 13:01             ` Konstantin Ryabitsev
  2021-09-27 15:28             ` StarBrilliant
  0 siblings, 2 replies; 15+ messages in thread
From: Bruno Wolff III @ 2021-09-27 10:21 UTC (permalink / raw)
  To: Roman Mamedov; +Cc: Nico Schottelius, el3xyz, wireguard

On Mon, Sep 27, 2021 at 14:36:28 +0500,
  Roman Mamedov <rm@romanrm.net> wrote:
>On Mon, 27 Sep 2021 04:14:35 -0500
>Bruno Wolff III <bruno@wolff.to> wrote:
>
>> This isn't a simple problem. The assumption is that someone is seeing
>> your network traffic and blocking it.
>
>The assumption is that there's an appliance at the ISP which has a DROP rule
>for UDP with 4 fixed bytes at a fixed offset. It has five hundreds other rules
>to process as well, so it can't spend "too much" time on specifically WG.
>
>> They are still going to see it  even if you disguise it.
>
>With obfuscation there would be UDP packets of random junk, and it would be a
>much harder job to come up with a rule to drop those without affecting
>anything else.

If your ISP is blocking your Wireguard traffic call them up and complain.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: WireGuard with obfuscation support
  2021-09-27 10:21           ` Bruno Wolff III
@ 2021-09-27 13:01             ` Konstantin Ryabitsev
  2021-09-27 13:48               ` Lonnie Abelbeck
  2021-09-27 15:28             ` StarBrilliant
  1 sibling, 1 reply; 15+ messages in thread
From: Konstantin Ryabitsev @ 2021-09-27 13:01 UTC (permalink / raw)
  To: Bruno Wolff III; +Cc: Roman Mamedov, Nico Schottelius, el3xyz, wireguard

On Mon, Sep 27, 2021 at 05:21:57AM -0500, Bruno Wolff III wrote:
> > With obfuscation there would be UDP packets of random junk, and it would be a
> > much harder job to come up with a rule to drop those without affecting
> > anything else.
> 
> If your ISP is blocking your Wireguard traffic call them up and complain.

There have been times when I found myself briefly at a location that didn't
allow wireguard traffic, like an airport or a public library. Complaining
wouldn't have been a useful course of action to take, since I needed a
solution at that particular time and place.

-K

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: WireGuard with obfuscation support
  2021-09-27 13:01             ` Konstantin Ryabitsev
@ 2021-09-27 13:48               ` Lonnie Abelbeck
  0 siblings, 0 replies; 15+ messages in thread
From: Lonnie Abelbeck @ 2021-09-27 13:48 UTC (permalink / raw)
  To: Konstantin Ryabitsev; +Cc: WireGuard mailing list



> On Sep 27, 2021, at 8:01 AM, Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> 
> On Mon, Sep 27, 2021 at 05:21:57AM -0500, Bruno Wolff III wrote:
>>> With obfuscation there would be UDP packets of random junk, and it would be a
>>> much harder job to come up with a rule to drop those without affecting
>>> anything else.
>> 
>> If your ISP is blocking your Wireguard traffic call them up and complain.
> 
> There have been times when I found myself briefly at a location that didn't
> allow wireguard traffic, like an airport or a public library. Complaining
> wouldn't have been a useful course of action to take, since I needed a
> solution at that particular time and place.

Public hotspots may just be blocking UDP/51820, not DPI.

Some time ago Jason posted an iptables REDIRECT workaround at your WG "server" endpoint [1]

I have found typically either 443 or 4500 will work if 51820 is blocked.

Lonnie

[1] https://lists.zx2c4.com/pipermail/wireguard/2018-November/003503.html


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: WireGuard with obfuscation support
  2021-09-27 10:21           ` Bruno Wolff III
  2021-09-27 13:01             ` Konstantin Ryabitsev
@ 2021-09-27 15:28             ` StarBrilliant
  2021-09-27 15:59               ` Nico Schottelius
  1 sibling, 1 reply; 15+ messages in thread
From: StarBrilliant @ 2021-09-27 15:28 UTC (permalink / raw)
  To: wireguard

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 believe the original poster is located in China rather than other countries, because the word “Shadowsocks” was mentioned, which is the only operable proxy software there -- its obfuscation is strong, but is slow and never cryptographically proved safe.

I would highly recommend you to test Wireguard on a virtual host in China to experience how the DPI is carried out, or to run a VPN service for Chinese users. The DPI system tries to create evidences to fool the user into believing it to be a network congestion, rather than an interference. The traffic will get interrupted after a few days, with increased packet loss rate each day. After a certain number of days, all packets will get dropped.

For any of you who is curious: The DPI system uses a statistical model, which means you get a higher chance of blocking if the source ASN is from a data center rather ran residential Internet; or if your size / timing / number of packets also match the characteristics of web browsing in addition to the usual Wireguard pattern. The sensitivity can even be tuned so the interference becomes stronger during June, August, and October.

It is so unfortunate this situation affects 1/5 of the world population. The Chinese users used to be too optimistic about Wireguard. Developing an obfuscation plugin framework is not sufficient to fight against it, but there aren't too much that one can do.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: WireGuard with obfuscation support
  2021-09-27 15:28             ` StarBrilliant
@ 2021-09-27 15:59               ` Nico Schottelius
  2021-09-27 16:37                 ` StarBrilliant
  0 siblings, 1 reply; 15+ messages in thread
From: Nico Schottelius @ 2021-09-27 15:59 UTC (permalink / raw)
  To: StarBrilliant; +Cc: wireguard


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

Thanks a lot for the detailed explanation. While we have become a bit
off-topic (more of the why then the how) in regards to wireguard, I
think above explanation is important.

Wireguard's purpose is to be a secure VPN tunnel and I personally would
love if we can add "reliable" to its feature list. However that would
need more advanced support, like obfuscation is providing.

I'm not saying obfuscation is the only method, but compared to
a DPI with statistical analysis, I think we are pretty far away from
being reliable in hostile networks. Maybe extending wireguard with
obfuscation is out of scope of this project, but then it might be an
idea to wrap the wireguard traffic into other protocols.

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?

Best regards,

Nico

--
Sustainable and modern Infrastructures by ungleich.ch

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: WireGuard with obfuscation support
  2021-09-26 12:09 WireGuard with obfuscation support el3xyz
  2021-09-27  0:53 ` Nico Schottelius
@ 2021-09-27 16:21 ` Jason A. Donenfeld
  1 sibling, 0 replies; 15+ messages in thread
From: Jason A. Donenfeld @ 2021-09-27 16:21 UTC (permalink / raw)
  To: el3xyz; +Cc: wireguard

Hey Evgeny,

There are some neat aspects of the approach here. Encrypting using the
pubkey has the nice effect of making packets look like noise while
also being sufficiently peer-linked that it might not be super
feasible to detect (though still possible I suppose).

I don't think we'd merge something like this into wireguard-itself,
unfortunately. Obfuscation is a bit of a cat and mouse game, and were
we to bake a handful of methods into wireguard, much focus would be
spent on detecting those, and then the whole thing would be moot.

From my own obfuscation projects, I've found the most effective
techniques involve mimicry of other explicitly-allowed protocols,
rather than just turning packets into noise, and mimicking the related
packet timing and length relations of those protocols too. It's
possible to do this in part using Markov chains, but also for your
likely use case, you may be able to just code logic for fake tcp +
http -looking sessions, or perhaps quic in the future.

But your likely use case is also not likely to be the same as others'
use cases for obfuscation. For example, while much obfuscation focuses
on censorship resistance, there's another corner that focuses on IDS
evasion, like hiding inside of Kerberos or RDP or even resembling
SIGTRAN packets. And even in the censorship resistance space, there
are often important tradeoffs to be made between performance and
detection: do you want your connection to be as speedy as possible, or
do you want to ensure that you won't be detected? What are the
repercussions of failure for each case? And moreover, what about when
targeted traffic shaping is used in connection with DPI or related
heuristics? In that case, a popular technique appears to be adding FEC
to packets. And so on and so forth.

This all is to say that the obfuscation game is a big rabbit hole of
sorts, and there's unlikely to be one solution for the many
applications of it.

For that reason, as I've written on this list before, I think
obfuscation ought to be in a layer above wireguard, not within it. You
can do this by setting the endpoint to be a localhost udp port, or
better, by writing a netfilter module or using something like NFQUEUE
to do it in userspace. While there's a lot of enthusiasm for
"pluggable transports" and such, I actually don't think it's a bad
idea to violate the layering distinction and borrow things like peer
public keys when that makes for a potentially slicker system.

For example, I could imagine a netfilter plugin that specifically
attaches to a wireguard interface, and uses config information from it
to do per-peer obfuscation, so that additional identities don't need
to be configured. An admin would run `iptables -t mangle -A OUTPUT -m
evgeny_wg_thing --out-iface wg0 -j EVGENYS_COOL_OBFS_THING_OUT &&
iptables -t mangle -A INPUT -m evgeny_wg_thing --in-iface wg0 -j
EVGENYS_COOL_OBFS_THING_IN` and then presto, everything would work
with no additional configuration.

Splitting out your ideas into something that runs adjacent to
wireguard but works intimately with it might require a little bit more
work in the short term, but I think long term that will lead to a more
sound design, and it could grow and morph all sorts of interesting
different modes.

Jason

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: WireGuard with obfuscation support
  2021-09-27 15:59               ` Nico Schottelius
@ 2021-09-27 16:37                 ` StarBrilliant
  0 siblings, 0 replies; 15+ messages in thread
From: StarBrilliant @ 2021-09-27 16:37 UTC (permalink / raw)
  To: Nico Schottelius; +Cc: wireguard

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2021-09-27 16:37 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-26 12:09 WireGuard with obfuscation support el3xyz
2021-09-27  0:53 ` Nico Schottelius
2021-09-27  7:11   ` Bruno Wolff III
2021-09-27  7:34     ` Roman Mamedov
2021-09-27  9:14       ` Bruno Wolff III
2021-09-27  9:36         ` Roman Mamedov
2021-09-27 10:21           ` Bruno Wolff III
2021-09-27 13:01             ` Konstantin Ryabitsev
2021-09-27 13:48               ` Lonnie Abelbeck
2021-09-27 15:28             ` StarBrilliant
2021-09-27 15:59               ` Nico Schottelius
2021-09-27 16:37                 ` StarBrilliant
2021-09-27  7:44     ` Nico Schottelius
2021-09-27  8:17       ` Fredrik Strömberg
2021-09-27 16:21 ` Jason A. Donenfeld

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).