Hi :), I can't give you an answer to your history questions, since I wasn't involved in the history of PTs but I have the feeling you have this fundamental question "Why we should work on an other PT, as long as the stuff which we already have works fine?" (?) Simple answer: You should always have an active role (beeing faster like the other party in development) and not a passive role (waiting until your stuff doesn't work anymore before you work on something new) in the fight against censorship. Best regards, Carolin Am Samstag, den 27.10.2018, 17:20 +0530 schrieb Piyush Kumar Sharma:

Hello all, I have a few specific questions related to the pluggable transports.

1.) I believe that obfs4 stops active probing(the latest problem as brought to notice by Ensafi et al, IMC 2015 and Shinying Cho, FOCI 2018), and hence discovering obfs4 Tor bridges using active probing is not possible. Is that true? If so, then we are good to go and hence we don't need any other pluggable transport to work for us as long as obfs4 is working?

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?

3.) I searched a lot but could not find the timeline in which pluggable transports were built. As in what was developed and deployed first, obfs4 or meek?

Regards

Piyush IIITD _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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