Re: Let's talk about obfuscation again

[Brian Candler <b.candler@pobox.com>]

> Domain fronting seems like the stealthiest option to me (and if anyone has a reliable way to
> detect domain fronting, I would love to hear about it!). But that doesn?t get you UDP (and NAT
> traversal); perhaps VOIP/WebRTC mimicry could work?

I think this is a game you can't win against a suitably motivated adversary.  Such an adversary can and will decode the payload to see if it makes sense.

For example: an apparently unencrypted VOIP/WebRTC stream, but one which contains "random" payload (i.e. which doesn't decode properly through the declared codec, or decodes to noise) may be interpreted as an encrypted phone call, and blocked on that basis alone, even if it's not obvious it contains data.

It would also be massively inefficient.  On the one hand, you'd have to send a stream of padding packets when there is no data to send, to look like an idle phone/video call.  On the other hand, when you *do* have data to send, you would have to constrain your bandwidth so you don't burst above a level of traffic which such a call would normally generate.

OK, so what about changing wireguard to use TCP and TLS on port 443? It's still going to look very anomolous compared to a "normal" web exchange.  Conceivably it might be mistaken for a websockets-based chat application or XMPP; but any adversary who wants to block wireguard is presumably going to want to block encrypted chat too.

In summary: I think wireguard is a tool for connecting together island networks, over an untrusted but cooperative intermediate network.  I don't think it should turn into a tool for steganography or policy busting.