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

[Lorenz Kirchner]

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 at 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20120815/9e92cdb0/attachment.html>