There was a post on the tor-talk mailing list saying that a recent DPI
upgrade to Cyberoam firewalls gives them the ability to detect and block
several of Tor's pluggable transports, including meek:
https://lists.torproject.org/pipermail/tor-talk/2016-May/040898.html
The poster and I investigated and we think we know what they're doing.
Recall that meek uses a web browser (Firefox 38) to camouflage its HTTPS
requests. The Cyberoam devices are blocking TLS connections that have
Firefox 38's TLS signature and SNI equal to one of our three front
domains:
www.google.com,
a0.awsstatic.com, or
ajax.aspnetcdn.com.
Basically, they blocked meek, which looks like Firefox 38, by blocking
Firefox 38, then reduced the damage by limiting the blocking to a small
number of domains.
The blocking is deliberate, as the poster confirmed by talking to
Cyberoam support. The connections get logged as a Tor Proxy attempt and
the DPI is looking for obfs*, ScrambleSuit, and meek.
This style of detection has the obvious collateral damage of blocking
Firefox 38 users. Indeed, we tried using Firefox 38 downloaded from
https://download-installer.cdn.mozilla.net/pub/firefox/releases/38.8.0esr/
to browse
https://www.google.com/, and it was blocked. However, changing
the domain name, even using
google.com instead of
www.google.com, was
unblocked. Similarly, changing the front domain in Tor Browser to
google.com unblocked meek. Finally, the 6.0a5 alpha release of Tor
Browser, which is based on Firefox 45 and has a different TLS signature,
worked without any changes. In summary:
TB 5.5.5 meek to
www.google.com BLOCKED
Firefox 38 to
www.google.com BLOCKED
TB 5.5.5 meek to
google.com not blocked
TB 6.0a5 meek to
www.google.com not blocked
It is possible that this blocking strategy is feasible because there
are, by now, few users of Firefox 38, which was released a year ago.
According to
http://gs.statcounter.com/, Firefox 38 is now only 0.38% of
desktop browsers, compared to 12.41% when it was released. The current
value for Firefox 45 is 10.69%.
http://gs.statcounter.com/chart.php?device=Desktop&device_hidden=desktop&multi-device=true&statType_hidden=browser_version®ion_hidden=ww&granularity=monthly&statType=Browser%20Version®ion=Worldwide&fromInt=201504&toInt=201604&fromMonthYear=2015-04&toMonthYear=2016-04&csv=1
Date Firefox.38.0 Firefox.45.0
2015-04 0.38 0.00
2015-05 5.81 0.00
2015-06 12.41 0.00
2015-07 3.65 0.00
2015-08 0.94 0.00
2015-09 0.93 0.00
2015-10 0.72 0.00
2015-11 0.67 0.01
2015-12 0.51 0.01
2016-01 0.57 0.03
2016-02 0.43 0.37
2016-03 0.40 4.72
2016-04 0.41 10.69
One lesson from this is that we were right to worry about TLS
fingerprinting. Implementers should think about how to have some agility
in their fingerprint. The other is that browser updates are rapid, and a
given fingerprint can quickly become obsolete. (To put it in Dead Parrot
terms, it's not dead, it's pining for the fjords.)
One workaround is to use the 6.0a5 alpha release, which is based on
Firefox 45 and has a different TLS signature.
https://blog.torproject.org/blog/tor-browser-60a5-released
Another solution is to change the front domain to something else, for
exmaple using
google.com instead of
www.google.com. Instructions for
changing the front domain are here:
https://trac.torproject.org/projects/tor/wiki/doc/meek#Howtochangethefrontdomain