problem with bridges and a suggestion

[frank]

hi steve,

>Perhaps other ways of hiding it are needed. As it is, it would be
>trivial to connect via ssl and verify if a machine talks onion router.
>It might be harder if there were multiple protocol paths into it. What
>if I connect on port 25  and get a normal mail server, then start tls
>from within protocol and use a command to switch to onion routing. I
>connect on port 636 and its ldap first. 993 and its IMAP over ssl.

that's it!  to use a general protocol even like udp 53 to act as a tunnel for tor negotiation traffic.

sincerely,
		 
frank
2010-05-27

-------------------------------------------------------------
sender: Stephen Carpenter
sending date: 2010-05-27 00:01:47
receiver: or-talk
cc: 
subject: Re: problem with bridges and a suggestion

On Tue, May 25, 2010 at 7:51 AM,  <andrew at torproject.org> wrote:
> On Tue, May 25, 2010 at 05:18:44PM +0800, for.tor.bridge at gmail.com wrote 1.3K bytes in 36 lines about:

> : this morning, I got some new bridges through a hidden https proxy and
> : established a TOR circuit, but after some time, I lost the connection
> : and couldn't  establish a TOR circuit any more.
>
> Can you send debug logs to tor-assistants at torproject.org with what
> happens when your client tries to connect to the bridges?
>
> : from my knowledge to china's blocking methods, I believe they found my
> : newly got bridges through network traffic protocol analysis, and
> : blocked them.
>
> This is unlikely.  In our experience, they are merely blocking IP:Port
> combinations.

The question though is... how do they find them? Sure, you can get the
directory list, scrape the common bridge lists. However... this pretty
quickly is just "Whack a Mole". You have to imagine that they are
smart enough to figure that a person who was using tor yesterday, is
probably looking for a new bridge today.

Once you know who, even if its a small subset, is using tor, and smart
enough to find bridges as you shut them down, well... it wouldn't be
hard to watch them, and identify which connections of theirs are
bridges, and then push out new block lists. Even if I can't prove that
your connection from port x to port y is a tor connection, I can still
connect to the same remote port and negotiate an ssl connection myself
and verify if its a bridge. Hell, it could be automated.

It may not be 100%, but, it doesn't really need to be. Its not like
you need all the users all the time, just enough to raise the bar and
cut down the numbers.

> : use a general protocol for TOR clients to interact with bridges, so
> : that they can't distinguish the traffic between TOR clients and
> : bridges,
> : so that they can't find new bridges got through private ways.
>
> Tor traffic through bridges vs. public relays is the same.  There is not
> a special "bridge connection".  See
> https://www.torproject.org/faq#RelayOrBridge, also that text needs to be
> updated to reflect China's uniqueness in filtering Tor public relays.
>
> : the general protocol could be https which is encryption protected;
>
> It is already.  What may be unique is we start the connection with a TLS
> renegotiation.  This is probably starting to stand out as unique now
> that OpenSSL decided to everyone used renegotiation incorrectly and
> almost all operating systems have erroneously disabled this
> functionality by default.  See
> https://www.torproject.org/faq#KeyManagement

Perhaps other ways of hiding it are needed. As it is, it would be
trivial to connect via ssl and verify if a machine talks onion router.
It might be harder if there were multiple protocol paths into it. What
if I connect on port 25  and get a normal mail server, then start tls
from within protocol and use a command to switch to onion routing. I
connect on port 636 and its ldap first. 993 and its IMAP over ssl.

Perhaps the secret command to initiate the protocol could be part of
the bridge description?

-Steve
***********************************************************************
To unsubscribe, send an e-mail to majordomo at torproject.org with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/