[WireGuard] Options to obfuscate WireGuard traffic?

Bin Jin bjin at ctrl-d.org
Fri Jul 8 08:56:53 CEST 2016

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



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

More information about the WireGuard mailing list