[tor-dev] obfs4, meek, active probing and the timeline of pluggable transports

[Michael Rogers]

On 27/10/2018 12:50, Piyush Kumar Sharma wrote:
> 2.) What was the motivation to bring in meek as a pluggable transport,
> given the fact that obfs4 works great to cover all the existing problems
> with Tor detection. Was the motivation just the fact that, it will be
> much easier for the users to use meek than obfs4 or something other than
> this?

Hi Piyush,

I'm not a Tor dev but I'll try to answer this.

To use obfs4 the client needs to know the IP address of an obfs4 bridge.
If these addresses are distributed in a public or semi-private way,
eventually the adversary may learn them in the same way that clients do,
in which case they can be blacklisted without active probing.

Meek allows the client to connect to any server that belongs to a "front
domain". If the front domain also hosts a lot of popular services or
important infrastructure then the adversary may be reluctant to block
it, in which case it isn't necessary to keep the front domain secret
from the adversary.

Until recently, Meek used AWS and Google App Engine as front domains. I
believe those services have stopped supporting domain fronting, but a
similar tactic may soon become possible with encrypted SNI, which is now
supported by Cloudflare.

If anyone on the list knows whether/when we're likely to see a pluggable
transport based on encrypted SNI I'd love to hear about it.

Cheers,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x11044FD19FC527CC.asc
Type: application/pgp-keys
Size: 16659 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20181029/9b987243/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20181029/9b987243/attachment.sig>