Let's talk about obfuscation again

[Jason A. Donenfeld]

Hey SB,

Thanks for the detailed post and insights.

Indeed obfuscation is an extremely useful tool. WireGuard itself is
derived from an exfiltration mechanism of mine, and so I've written
quite a few different obfuscation modules for that. When the core
WireGuard engineering becomes a bit more relaxed (right now it's
pretty intense), I may devote some effort into cleaning these up and
making them available as generic methods for whatever packet flow.

One thing to consider with obfuscation is: what type do you need and
for what purpose? What is your adversary like, and what policies are
they trying to enforce? For example, any one of these methods are
useful in a particular circumstance:

- Turn the entire stream into noise with something like xchacha or aes-pmac-siv.
- Turn the stream into noise and then walk a markov chain to generate
something that looks like HTML.
- Turn the stream into noise and then walk a markov chain to generate
something that looks like h264.
- Turn the stream into noise and then walk a markov chain to generate
something that looks like TLS 1.0.
- Turn the stream into noise and then encode the traffic as DNS requests.
- Turn the stream into noise and then walk a markov chain to generate
something that looks like DNS.
- Generate a training set using traffic gathered from eth0, turn the
stream into noise, and then use the training set to generate traffic
that looks like normal traffic.
- Generate a training set using traffic gathered from an implant on
another box, turn the stream into noise, and then use the training set
to generate traffic that looks like normal traffic.
- Manually provide a hand crafted training set, turn the stream into
noise, and then use the training set to generate traffic that looks
like normal traffic.
- Turn the stream into noise, and manually encode that into some given format.
- Turn the stream into noise, and then inject as corrupt ethernet frames.
- Turn the stream into noise, and then delay existing packets with a
modulated encoding to create a side channel.

The list goes on. These have all been useful in different
circumstances, and there are many more like them. I'm not too familiar
with the pluggable transports project, but my understanding is that it
is motivated by precisely this insight: there are many valid and
useful means of obfuscation, each of which is useful and has different
trade-offs. So why not make it pluggable? I generally don't like
mega-abstracted and pluggable big complicated things, as a general
taste, but here I think one has a decent argument as to why this might
make sense.

So of your suggestions, the most compelling one is:

> - Remain plaintext, but fix padding and timing problem,
>  relying Pluggable Transport [4] plugins to do the remaining work.
>  (I really recommend this solution.)

This is generally what I'd recommend too, but I'm not sure I follow
the logic of the padding and timing. Should not a proper pluggable
transport be doing this on its own already? Adding random padding to
all packets, and delaying statistically similar ones randomly as well?
Especially for the padding aspect, there's little reason why a
pluggable transport should not already be doing this.

Jason