Let's talk about obfuscation again

[Dennis Jackson]

On Thu, 6 Sep 2018 17:19:57 +0200
Fredrik Strömberg <stromberg at mullvad.net> wrote:

>> First of all, censorship circumvention is an important societal
>> problem to solve. It is also clearly outside of the scope of
>> WireGuard. Any suggested protocol change with that motive will
>> increase the complexity of the code base, which increases the risk
>> of vulnerabilities. This would hurt all WireGuard users.

Amen! 

On Thu, 6 Sep 2018 10:45:24 -0400
George Walker <georgewalkeriv at gmail.com> wrote:

> The objective of cleaning as described seems to be to make the
> protocol indistinguishable from exchanging random payloads. But are
> there any common protocols of commercial importance that are so
> inscrutable? If I saw such random-looking UDP payloads on the wire I
> would suspect malware c&c, file sharing (who remembers FreeNet?), or
> a tunnel, depending on data volume and direction —nothing I would
> hesitate to block (or flag as suspicious) if I were running a big
> traffic classifier.

There is a few different purposes served by this transform: 

a) By having a uniformly random stream, its much easier to plug in to
various mimicry tools (as you suggest) since you know the input data
doesn't contain any meaning. There's some good work from the Tor people
on this kind of thing. For example, 'cleaned' traffic could be made to
look like TLS, without doubly encrypting every packet with the TLS key,
instead the UDP data can be passed through directly. 

b) From a surveillance perspective, it becomes harder to identify and
record traffic. The classification goes from being "WG-VPN" to "???".
This makes the analysts job a bit harder. Increasing labour costs is
probably more painful for such entities than anything else. 

c) It forces a censor to move from a blacklisting approach  to a
whitelisting approach. As you say, this won't stymie the great firewall
of China but developing a rule to block traffic which looks "too
random" without too many false positives requires a lot of resources
and we can exploit this. 

Best,
Dennis 

-- 
PGP Fingerprint: 5B93 F0B9 D6A8 9BC1 546B C98C 6105 A775 8CD2 46AC
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20180906/5bda660a/attachment.asc>