3.5.4-meek-1 (meek bundles with browser TLS camouflage)
Please try these bundles, which are configured to run the meek transport automatically. What's different about these than past meek bundles, is that they use a web browser extension to make the HTTPS requests, so that the TLS layer looks like Firefox. They are built on top of the recent 3.5.4 release so they have the OpenSSL Heartbleed fix. https://people.torproject.org/~dcf/pt-bundle/3.5.4-meek-1/ With luck, the bundles will work for you without any special configuration. If you look at your network traffic while you are using them, you will see some HTTPS connections to www.google.com, and nothing to any Tor bridge or any protocol other than HTTPS. The bundle should take care of starting up the extension and killing it when it is done. If it doesn't, it is a bug. There is a known bug (#11429), which is that on Mac you will see two dock icons. The second one is the one that is running the extension. David Fifield
On Fri, Apr 11, 2014 at 02:45:56PM -0700, David Fifield wrote:
Yep. Looks good, works out of the box for me. Nice. A bit slower than normal Tor use -- what's the overhead that meek introduces in terms of number of bytes that I send/receive compared to the 'real' underlying bytes? Or might this slowness be that my cpu and local computer is quite slow, so it's taking a while to load a whole second firefox in the background? Or maybe this is the wrong list to ask this question. :) Also, is there a reason your bridge needs to still be on 0.2.4.6-alpha-dev? https://globe.torproject.org/#/bridge/49395CD2424DF8ACFB4D580548A315A199EBD3... --Roger
On Fri, Apr 11, 2014 at 10:08:41PM -0400, Roger Dingledine wrote:
For every chunk of data that the transport reads from tor, it adds an HTTP header plus another layer of TLS. A chunk is usually 586 bytes, but it could be bigger if more than one cell is buffered between tor and the transport. It can be many kilobytes during bootstrapping or bulk downloads. A source of extra latency is the additional hop your traffic takes through App Engine. My guess is that this matters more than byte overhead. The other source of extra latency is serialization of requests. You have to wait for the response to your first request before you can issue a second. My guess is that this matters more than the extra hop. Here are some latency measurements we made: https://trac.torproject.org/projects/tor/ticket/10935#comment:7 The second browser instance probably doesn't matter much. The serialization and deserialization between the transport plugin and the browser extension is more expensive CPU-wise than I anticipated, but I don't think it's a bottleneck. Starting up the second browser is a one-time cost.
Also, is there a reason your bridge needs to still be on 0.2.4.6-alpha-dev? https://globe.torproject.org/#/bridge/49395CD2424DF8ACFB4D580548A315A199EBD3...
There's no good reason. I'll take care of it. But we are actually looking for someone with experience running fast bridges to run a fast bridge located close to App Engine. There's no reason it has to be me and it's better if it's not me. David Fifield
David Fifield:
Testing: TorBrowserBundle-3.5.4-meek-1-osx32_en-US.zip Platform: Mac OS X 10.9.2 (13C64) Processor: 2.3GHz Intel Core i7 Memory: 16 GB 1600 MHz DDR3 Graphics: NVIDIA GeForce GT 750M 2048 MB Display: 15-inch (2880 x 1800 Retina) TBB Launches successfully: yes, *****but launches two browsers? Connects to the Tor network: yes Browser toolbars and menus work, tab dragging works: yes All extensions are present and functional: yes - HTTPS-Everywhere 3.4.5 - NoScript 2.6.8.17 *****Older version? - TorButton 1.6.7.0 *****Older version? - TorLauncher 0.2.5.1 *****Older version? WebBrowsing works as expected - HTTP, HTTPS, .onion browsing works - HTML5 videos work on http://videojs.com/ and YouTube - http://ip-check.info/?lang=en - ok - https://panopticlick.eff.org/ - only one in 674,172 , 19.36 bits of identifying information - html5demos.com/web-socket - Not Connected / Socket Closed SOCKS/external apps work as expected: yes (Torbirdy, Bitcoin-QT) Noticeably slower. SSL Client is bad according to https://www.howsmyssl.com/. Connections to google.com, evintl-oscp.versigin.com, and calendar.google.com.
On Sat, Apr 12, 2014 at 12:22:47PM +0000, Wilton Gorske wrote:
TBB Launches successfully: yes, *****but launches two browsers?
Thanks for testing. Launching two browsers is expected--the second browser is the one that hosts the browser extension that meek uses to make its HTTP requests (see https://trac.torproject.org/projects/tor/ticket/11183 and https://trac.torproject.org/projects/tor/wiki/doc/meek#HowtolooklikebrowserH...). But the fact that it shows two icons on OS X is a bug, one I don't know how to fix yet (https://trac.torproject.org/projects/tor/ticket/11429).
Connections to google.com, evintl-oscp.versigin.com, and calendar.google.com.
google.com and evintl-oscp.verisign.com are expected. That's because all your traffic is being routed through Google's App Engine servers. I'm surprised at calendar.google.com though. how did you get those names? Through reverse DNS? Google can you different frontend IPs and maybe one of them reverse-resolves to calendar.google.com. David Fifield
On Fri, Apr 11, 2014 at 02:45:56PM -0700, David Fifield wrote:
TBB Launches successfully - OK Connects to the Tor network - OK Browser toolbars and menus work. Tab dragging works. - OK DNS - No leaks observed (wireshark) OpenSSL - 1.0.1g All extensions are present and functional - OK - HTTPS-Everywhere 3.4.5 - NoScript 2.6.8.17 - Torbutton 1.6.7.0 - TorLauncher 0.2.5.1 WebBrowsing works as expected - OK - HTTP, HTTPS, .onion browsing works - HTML5 videos work - ip-check.info - OK - samy.pl/evercookie - OK (new identity clears cookie) - phoul.github.io - websocket enabled Other notes: - HTTPS-Everywhere & NoScript both auto-updated.
participants (4)
-
Colin C. -
David Fifield -
Roger Dingledine -
Wilton Gorske