Hi everybody,
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.
Loz
On Wed, Aug 15, 2012 at 4:32 AM, Roger Dingledine arma@mit.edu 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays