Re: [tor-dev] obfs4, meek, active probing and the timeline of pluggable transports
On Sat, Oct 27, 2018 at 05:20:06PM +0530, Piyush Kumar Sharma wrote: > 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? For questions like this, see our metrics timeline page: https://trac.torproject.org/projects/tor/wiki/doc/MetricsTimeline The three transports meek, ScrambleSuit, and obfs4 were deployed in Tor Browser roughly at the same time. ScrambleSuit was a predecessor of obfs4 that also deals with active probing. meek and ScrambleSuit were first in 4.0-alpha-1 (Aug 2014) and 4.0 (Oct 2014). obfs4 was first in 4.5-alpha1 (Nov 2014) and 4.5 (Apr 2015). ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfs4, meek, active probing and the timeline of pluggable transports
Firefox Nightly let’s you manually enable it. I’d wait until at least Firefox and Chromium add support to avoid setting off red flags for a censor. Having collateral damage is important with pluggable transports Cordially, Nathaniel On Mon, Oct 29, 2018 at 10:25 AM Nicolas Vigier wrote: > On Mon, 29 Oct 2018, Michael Rogers wrote: > > > > > 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. > > There was a thread on this topic recently: > https://lists.torproject.org/pipermail/tor-dev/2018-September/013453.html > > So it seems the first step is having major adoption by browsers and > websites, before using it for anti-censorship. Otherwise censors could > just block all encrypted SNI requests. > > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfs4, meek, active probing and the timeline of pluggable transports
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 0x11044FD19FC527CC.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfs4, meek, active probing and the timeline of pluggable transports
Obfs4 can apparently solve most of the problems pertinent to identifying Tor bridge traffic by inspection of TLS headers... Meek relies on SNI field of TLS headers to communicate to bridges via a "front end ". >From an overall cursory glance it appears that obfs4 was introduced in 2014 while Meek came later (probably 2015). Thus why would one choose to go back to relying on TLS traffic that could potentially be identified by the adversary is a bit unclear (considering that there already existed a superior solution then , i.e. obfs4). On Sun, Oct 28, 2018, 03:37 Carolin Zöbelein wrote: > 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 > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfs4, meek, active probing and the timeline of pluggable transports
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 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfs4, meek, active probing and the timeline of pluggable transports
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
