On 12/21/2011 09:31 PM, David Fifield wrote: > A few months ago, Roger wrote about ideas for getting more bridge > addresses > (https://blog.torproject.org/blog/strategies-getting-more-bridge-addresses). > One of the ideas is to make lightweight bridges that can run in a web > browser. I and some others have been working on this for a few months. I > want to promulgate our ideas and code among you developers, and ask for > your opinions and suggestions.
Thanks, I think this is great work! > > == Summary > > The overall idea is a little applet that can be installed on a web page. > We call it a "flash proxy." As long as you have the page open in your > browser, you are a proxy. These proxies may only last a few seconds or > minutes, but the code we've written allows switching between active > proxies in a fairly transparent manner, enough to make web browsing > possible. The idea is that web browsers provide a large, diverse, and > ever-changing pool of bridge addresses. A censor will not be able to > block all of them in a timely manner--at least that's what we hope. > > This is our overview and demo page. Down at the bottom of the page is a > flash proxy badge. > https://crypto.stanford.edu/flashproxy/ > > It's called a "flash proxy," and the implementation happens to be in > Flash, but the "flash" should rather make you think "quick." I'm pretty > sure the same thing can be done with WebSockets or other technologies. > That was my read at first - has anyone tried the basic concept with WebSockets? > == Howto > > You can easily but slightly artificially test the flash proxy transport > with this command: > $ tor UseBridges 1 Bridge 127.0.0.1:9001 Socks4Proxy > tor-facilitator.bamsoftware.com:9999 > (Make sure a flash proxy is running somewhere, and wait about 30 seconds > for a connection.) What's artificial about this example is that the > service at tor-facilitator.bamsoftware.com:9999 (the "connector") is > something you would normally run on your own computer. We run one on the > Internet for the ease of demos like this. See the instructions in the > README for how to test it more realistically. > That worked for me as expected: Dec 21 23:29:08.000 [notice] new bridge descriptor '3VXRyxz67OeRoqHn' (fresh): $7C03D29CA58BE8EED5F483F31A2DEDF6FD7CC444~3VXRyxz67OeRoqHn at 127.0.0.1 > We are using the torproject.org git server, so our code is > $ git clone git://git.torproject.org/flashproxy.git > https://gitweb.torproject.org/flashproxy.git > https://gitweb.torproject.org/flashproxy.git/blob/HEAD:/README > Though you need Adobe's Flash Player to *run* the flash proxy, you can > *build* it using only free software (details are in the README). > Thanks for ensuring that this works with Free Software! > == Architecture > > Most of the architecture is dictated by a limitation of web socket > technologies, namely that they can only make outgoing TCP connections, > and cannot receive connections. This leads to a funny model where the > proxy connects to the client, instead of the other way around. > > The pieces that work together are: > * Tor client (e.g. /usr/sbin/tor on the local host). > * Tor relay (e.g. /usr/sbin/tor on the Internet). > * Flash proxy, running in someone's web browser. Imagine that there are > many of these online at once, but they have a lifetime on the order > of minutes. > * Connector, a little program that sits between the flash proxy and the > Tor client, and receives connections from the proxy. It acts as an > upstream SOCKS4 proxy to Tor (but ignores whatever address Tor gives > it). The connector also does the switching between proxies as they go > offline. > * Facilitator, which keeps track of clients that need addresses, and > gives those addresses to proxies as they come online. We are running > one of these at tor-facilitator.bamsoftware.com:9002. > This all reduces to a very time limited set of bridges - they provide availability and nothing more. > A sample session goes like this: > 1. The user starts a connector and a Tor client. The connector sends its > address to the facilitator, so that a proxy will know where to > connect to. (We call this step "rendezvous.") > 2. A flash proxy appears in a browser and asks the facilitator for an > address. > 3. The facilitator sends a remembered client address to the proxy. > 4. The proxy connects to the client address. The client's connector > receives the connection. > 5. The proxy connects to a Tor relay, then begins copying data between > its two sockets. Where is the list of all facilitators? > > Something to note is that the flash proxy doesn't do any crypto. It is > just a dumb pipe for ciphertext. There are still three relay hops after > the proxy. (But the proxy effectively gets to pick the first hop.) > Perhaps TLS or HTTP would be a good idea? If the blocking of bridges is done by protocol fingerprinting, I worry that this will also be automatically blocked. > == Objections > > Doesn't this shift the problem from bridges begin blocked to the > facilitator being blocked, since the client has to send its address to > the facilitator? The short answer is yes, we expect the facilitator to > be permanently blocked by IP address, so the client must find a covert, > uncensorable channel over which to rendezvous. The good news is that > we've turned a big problem--how to make all your Tor traffic > unblockable--into a small problem--how to make a one-time, write-only > connection of a dozen bytes unblockable. This lesser constraint opens up > new possibilities, for example you could email your address to someone > you know and have them rendezvous on your behalf, even though you > couldn't push all your Tor traffic over such a channel. DNS names generated from a shared secret come to mind. > Isn't blocking by protocol/DPI still possible? Yes, there are many > components to circumvention, and bridge creation is just one part. > Against such a censor it will be necessary to layer some kind of > obfuscation, but that's an issue of its own. It also may be a revealing > signature for a client IP address to receive lots of incoming > connections, but how much this stands out we don't know yet. > You could transform the Tor client's first hop into something that looks a lot like HTTP. I think sjm was working on this? > == Shortcomings > > I should mention that the implementation doesn't live up to everything > I've stated above. The "rendezvous" step is just an HTTP POST to the > facilitator. Also, the connector re-registers itself unnecessarily: that > should happen only once, and thereafter the facilitator should remember > it. > > == Next steps > > Here are the next things I'd like to accomplish: > > * Get the proxy installed on more blogs and web pages. Currently it's > only on the demo page and on my web site, which only provide enough > proxies to have service about 60% of the time. I think the demo text is missing some bytes? > * Implement a bona fide rendezvous protocol. Though this is somewhat > separable from flash proxies themselves, it's essential for a complete > working system. We have done a couple of limited prototypes; please > ask me if you are interested in or have knowledge of this. Do you mean something similar to the way GNUnet does nat punching? > * Build an installer for client programs. This would be good to bundle in the Tor Browser bundle, I bet. > * Try a plain JavaScript proxy. I like that idea very much - I don't use Adobe anything and while I'd like to try it with Gnash, I'm not sure that Gnash is ready, is it? > Unfortunately this has been very much a spare-time project for me. I'd > love to share some of this development with anyone who's interested. > I've had a couple of people contact me about possibly supporting > development in various ways. > Thanks for working on this! > But what I'd like most of all are your comments and ideas. I really want > to invite discussion on the architecture, with the goal of making it > robust and secure. Though the system is already partly usable, I still > consider it a research project, not a finished product. Circumvention is > such a big topic I haven't covered all the details in this message, so I > value your clarifying questions. > Have you tried this with gnash? All the best, Jake _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
