[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