JavaScript anticensorship proxiesDavid Fifield
|
“Evading Censorship with Browser-Based Proxies.” David Fifield, Nate Hardison, Jonathan Ellithorpe, Emily Stark, Roger Dingledine, Phil Porras, and Dan Boneh.
Alexandre Allaire, Brian Duggan, Jorge Couchet, George Kadianakis, Griffin Boyce, Sathyanarayanan Gunasekaran, Chris Ball, tor-dev.
Tiny proxies that run in a web browser, using JavaScript and WebSocket.
Web site owners paste a little bit of HTML.
<iframe src="//crypto.stanford.edu/flashproxy/embed.html" width="80" height="15" frameborder="0" scrolling="no"></iframe>
Viewers see a little badge that turns their browser into a proxy while they are on the page. Proxies come and go all the time and are hard to effectively blacklist.
Blocking by address: The censor blocks packets based on a blacklist of source and destination addresses. (Addressed by this work.)
Blocking by content: The censor uses deep packet inspection (DPI) or measures side channels such as timing to classify the contents of a stream. (Addressed by traffic obfuscators such as obfsproxy.)
Comprehensive circumvention requires addressing both kinds of censorship. Doing so is now under development.
The key architectural constraint: browsers can’t receive connections. Instead we invert the usual proxy model and have the proxy connect to the client.
The client gives its address to the facilitator through an unblockable covert channel.
This sounds like pixie dust, except for the relaxed requirements of rendezvous: it may be
Techniques work for rendezvous that would not work for bulk bidirectional data transport.
Send email to a distinguished Gmail address, containing your client address encrypted with the facilitator’s public key:
To: flashproxyreg.a@gmail.com From: nobody@localhost Subject: client reg f8a52ca71f EzQODw0CJYvDX2CgMLW64hhDKQqBmXaNI5n3a0ReUxzPng29TK106Axsaem/JoFhSy+nYTgzLEFs jLXdb9KK71EB99CZnnPZLovg2nA+kzI6hSCaV3tBED963VrzaIPeXTNRyuzP9Hb6WEUs7QFtQUp2 40el+GEvLuiYrwzH2noqdizXw9QsMEgzxxgxNQ+ci1u1uuPF05uhFpMtsV/kxSebXNw6xm8xhjyU nlWFDSKH90YHOxBZrWnkG2DvEHgJc/OUFuZGiPqdXoBhmXKO1Pt2fK5cWCADxcwPVZYwjrSUmVQ0 TeHjOyEw/wOBQ/MhXAIcJLf5r67tvdxMZBaOSQ==
This decrypts to
client=1.2.3.4:9000
A process on the facilitator polls the mailbox and registers the addresses it receives.
The reverse proxy model means that the censored client must be able to receive connections (cannot be behind NAT). Flash proxies themselves may be behind NAT.
A potential solution to this is new browser technologies. We are looking (#5578) at WebRTC, which will allow browsers to make peer connections with built-in NAT traversal.
“The Tor Software Ecosystem,” Jacob Appelbaum and Roger Dingledine, 28 December 2012.
Measured at the facilitator.
https://blog.torproject.org/blog/combined-flash-proxy-pyobfsproxy-browser-bundles, 14 January 2013.
Measured at the WebSocket Tor bridge.
We logged whether proxies had set the opt-in cookie over the past two
weeks. 1
means opted in, unset
means no
preference, and --
means the proxy didn't even know it was
supposed to send a cookie.
Now with heights of bars normalized to 1.
Browser plugin (#7721, Cupcake for Chrome). Don't have to keep a tab open.
Facebook app (#6291), in development by the Open Technology Institute. Lightning talk with Brian Duggan at 29c3.
Standalone flash proxy
(#7944).
Why limit ourselves to a browser? apt-get install flashproxy
Combine flash proxy address diversity with obfsproxy fingerprinting resistance (#7167). Made even more compelling with a standalone bridge, which doesn't have to use WebSocket.
Install the badge on your web page.
<iframe src="//crypto.stanford.edu/flashproxy/embed.html" width="80" height="15" frameborder="0" scrolling="no"></iframe>
Opt-in your browser.
Install a browser plugin.
Add the badge to your Wikipedia skin. (Copy and paste into your “Custom JavaScript” setting.)
Look at bug reports and open tasks.
“If it’s not free software, then it sucks.”
git clone https://git.torproject.org/flashproxy.git
David Fifield <dcf@cs.stanford.edu>http://crypto.stanford.edu/flashproxy/ |