[WireGuard] Options to obfuscate WireGuard traffic?

[WireGuard] Options to obfuscate WireGuard traffic?

[Bin Jin]

Hello Jason,

Thanks for your work on WireGuard. I tried it and also read the
whitepaper. It looks really promising. Congratulations!

The reason I'm writing this email, is to learn how would WireGuard
work against traffic censorship from authority (particularly the
so-called deep packet inspection). Is it a goal or non-goal for
WireGuard to obfuscate the traffics and make them "indistinguishable"
from raw encrypted traffic?

Some background. Chinese government was doing disgusting things
against VPN (and other tunnelling protocols). OpenVPN and "ssh -D"
tunneling will easily be detected (by the their traffic pattern) and
interrupted (with server IP blocked for several hours). There are also
rumors saying that they are deploying machine learning techniques to
perform deep packet inspection for new protocols. The current most
widely used tunnelling program, Shadowsocks[1], relies sorely on
pre-shared key (and pre-agreed encryption method), and encrypt every TCP
and UDP packet with randomly generated IV (You can see [2]
for details). In this extreme way, it somehow works.

After reading the whitepaper, it's really a good signal to learn that
WireGuard is almost stateless, with state of the art authentication
and encryption. But I'm little worried that it's probably not enough
to work against really aggressive deep packet inspection:

1. The packet format is highly distinguishable. Particularly the
message type is limited to "0x01..04". The sender/receiver index,
timestamp and counter fields also have obvious pattern.

2. The handshake always happens first for once. But I understand it's
by design and we probably couldn't do anything about it.

I understand that it's not flexible to make major changes to the
protocol at this moment, as it's approaching to be finalized. Not
mention that such change will most likely hurt the performance badly.
I just want to know if it's flexible to extend the protocol in the
future. For example, add an option (disabled by default) to use
another pre-shared key to symmetrically encrypt the whole packet? It's
probably also necessary to make the size of the first three packet
types variable, but appending random number of random bytes to those
packets.

Thanks!

Regards,
Bin

[1]: https://shadowsocks.org
[2]: https://shadowsocks.org/en/spec/protocol.html

Re: [WireGuard] Options to obfuscate WireGuard traffic?

[Jason A. Donenfeld]

Hi Bin,

This is something I've thought about quite a bit. As a security
researcher I've done some research on network exfiltration from
rootkits, so here the indistinguishability attribute is interesting
too.

Generally speaking, WireGuard does _not_ aim to evade DPS,
unfortunately. There are several things that prevent this from
occurring:

a) The first byte, which is a fixed `type` value.
b) The fact that `mac2` is most often all zeros.
c) The fixed length of handshake messages.
d) The unencrypted ephemeral public key.

> The sender/receiver index,
> timestamp and counter fields also have obvious pattern.

These are not actually problems. The sender/receiver indices are
random 32-bit numbers and cannot be predicted. The timestamp is not
sent in the clear, but rather is encrypted and therefore requires the
private key of the receiver to see that it's a timestamp.


Let's go through one by one with these problems. The easiest one, (b),
could be fixed by just filling `mac2` with random data when not in
use. The hardest one, (d), is not a problem, I don't think, because
these public keys are still uniformly distributed. The amount of
public keys that would have to be collected in order to not rule out
false positives is way too big, I suspect. So, not a problem in the
end.

(a) and (c) are the tricky ones. There are a few ways to fix this. The
first is: live with (c), get rid of (a), and then make transport
messages larger, so that the type can be inferred from the length.
This might not work well with sophisticated DPS though. Alternatively,
(a) could be removed, (c) could be made random, and a different
(random) UDP port could be used. Here, though, a sophisticated DPS
could observe timings between different UDP ports on the same host.
Another approach would be moving to only PSK, and eschewing the
handshake; this seems to be what Shadowsocks chose to do. What else
could be done for (a) and (c)? Interesting discussion to be had about
these...


> widely used tunnelling program, Shadowsocks[1],

Looking at this briefly, it looks like authentication was added on as
an afterthought to Shadowsocks, and unfortunately uses HMAC-SHA1. It's
too bad they didn't use an AEAD from the start.

> I understand that it's not flexible to make major changes to the
> protocol at this moment, as it's approaching to be finalized. Not
> mention that such change will most likely hurt the performance badly.
> I just want to know if it's flexible to extend the protocol in the
> future. For example, add an option (disabled by default) to use
> another pre-shared key to symmetrically encrypt the whole packet?

Actually there's already a PSK mode. I suppose it's possible to
leverage this to add an obfuscation layer. This is likely the most
robust way of doing things, in fact. I'll give this some more thought,
but it's kind of unlikely that I'll incorporate this into the
codebase.

Regards,
Jason

Re: [WireGuard] Options to obfuscate WireGuard traffic?

[Jason A. Donenfeld]

On Fri, Jul 8, 2016 at 12:26 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> a) The first byte, which is a fixed `type` value.
> b) The fact that `mac2` is most often all zeros.
> c) The fixed length of handshake messages.
> d) The unencrypted ephemeral public key.

How could I forget?

e) Incremental nonce.

This system would clearly need to be replaced by random IVs -- using
something like xchacha20. Inside then would be an encrypted sequence
number to prevent replay attack.

Re: [WireGuard] Options to obfuscate WireGuard traffic?

[Jonathan Rudenberg]

> On Jul 8, 2016, at 06:26, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>=20
> The hardest one, (d), is not a problem, I don't think, because
> these public keys are still uniformly distributed. The amount of
> public keys that would have to be collected in order to not rule out
> false positives is way too big, I suspect. So, not a problem in the
> end.

My understanding is that it is possible to detect even Curve25519 public =
keys on the wire, given enough examples of traffic. The Elligator paper =
provides some examples of algorithms for doing so and provides a system =
that makes them completely indistinguishable from random strings: =
https://elligator.cr.yp.to/

Here is some documentation of applying it to Curve25519: =
https://www.imperialviolet.org/2013/12/25/elligator.html=

Re: [WireGuard] Options to obfuscate WireGuard traffic?

[Jason A. Donenfeld]

Ahh, I had forgotten about Elligator. Thanks for that. Paper here:
https://elligator.cr.yp.to/elligator-20130828.pdf

Re: [WireGuard] Options to obfuscate WireGuard traffic?

[Bin Jin]

> Actually there's already a PSK mode. I suppose it's possible to
> leverage this to add an obfuscation layer. This is likely the most
> robust way of doing things, in fact. I'll give this some more thought,
> but it's kind of unlikely that I'll incorporate this into the
> codebase.

I see. It's a bit pity to learn that, but I understand it's kind of
ugly and probably still not enough (due to fixed packet length for
first two types). Thanks for explaining every details.

Re: [WireGuard] Options to obfuscate WireGuard traffic?

[Bruno Wolff III]

On Fri, Jul 08, 2016 at 21:13:02 +0200,
  Bin Jin <bjin@ctrl-d.org> wrote:
>> Actually there's already a PSK mode. I suppose it's possible to
>> leverage this to add an obfuscation layer. This is likely the most
>> robust way of doing things, in fact. I'll give this some more thought,
>> but it's kind of unlikely that I'll incorporate this into the
>> codebase.
>
>I see. It's a bit pity to learn that, but I understand it's kind of
>ugly and probably still not enough (due to fixed packet length for
>first two types). Thanks for explaining every details.

I'm not sure it makes sense to combine the hiding of traffic with the 
secure tunneling of traffic. There are going to be different efficiency 
trades and there are going to be different traffic patterns available 
to try to blend into. So different people are going to want to use 
significantly different solutions to that problem. Given the design goals 
of wireguard, I don't think it is something that would be particularly 
good to combine with steganography.

I think for normal people this is more of a political problem then a 
technical problem. We need real net neutrality, with ISPs not allowed 
to block traffic based on content. (e.g being prohibited from charging 
people extra to allow the use of VPNs.) We need governments not passing 
laws to make people compromise their own security (e.g. RIP in the UK), 
nor should they prevent companies from providing applications or services 
where the end user can guaranty their security (as some people are trying 
to do in the US). Using strong unbreakable encryption when communicating, 
should be the norm, not something you need to hide.