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

[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

[Carolin Zöbelein]

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

Post by 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
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[Sambuddho Chakravarty]

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).

Post by Carolin Zöbelein
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

Post by 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
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Michael Rogers]

Post by Piyush Kumar Sharma
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

[Nicolas Vigier]

Post by Michael Rogers
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.

[Nathaniel Suchy]

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

Post by Nicolas Vigier

Post by Michael Rogers
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.

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
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[David Fifield]

Post by Piyush Kumar Sharma
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).