Re: [tor-relays] Help the Tor Project by running a fast unpublished bridge

I'm not a tor expert but I am in China and have been using tor... I brought this up before and I still feel that tor would benefit from having special (entry)relays inside the GFW that have a reliable link to relays outside the GFW. Clients inside GFW could then always connect to these relays. Actually, probably tens of thousands of people have VPN connections and they could host such relays to provide access to clients, even such that might be completely blocked from accessing addresses outside the GFW, which, sadly, that is not so uncommon either.

Of course it would be great to reveal as little information as possible about such special relays in public... and continue to make the tor connections as un-conspicuous as possible

20 mbit fiber connections are rapidly becoming commonplace in China. VPNs are commonplace already and I think in the case of GFW the tor project could make use of this situation.

I'd love to see some sort of an easy deployable tor relay package that could listen on both the chinese and vpn address and relay traffic between the two...

or even develop a free tor-super-relay package with a dedicated built-in tor-exclusive vpn... ok maybe that's too much.. just a thought from a user

keep up the good work.

On Wed, Aug 15, 2012 at 4:32 AM, Roger Dingledine <arma@xxxxxxx> wrote:

On Tue, Aug 14, 2012 at 05:13:56PM +0200, tor-admin wrote:
> My understanding of bridge detection was, that Chinas GFW is able to detect
> the Tor SSL handshake and does active bridge probing after a successful
> connection to a (for the GFW) unknown bridge IP. So they should be able to
> block any bridge publish or unpublished very quickly, if someone from behind
> the GFW connects to a bridge. Am I missing something?

We haven't made a big fuss about it, but Tor 0.2.3.17-beta uses a new
ciphersuite in the ssl client hello, and I believe China's current DPI
doesn't notice it.

https://lists.torproject.org/pipermail/tor-talk/2012-June/024511.html

The extra-fun part is that if a Tor 0.2.2 client connects to the bridge,
it triggers the probing you describe (and thus the blocking). But if
only Tor 0.2.3.17+ clients connect, no probing (and thus no blocking).

Obfsproxy's obfs2 protocol is way better at not getting blocked currently;
but I'm holding out for an obfs3 release, with a new protocol that's
harder to DPI for, before we push for a big rollout there.

--Roger

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