[tor-dev] Vanilla ORPorts burning PT ports? (was: Internet-wide scanning for bridges)

[Vlad Tsyrklevich]

I asked Isis about this on #tor-dev and she confirmed that this is indeed
possible. I think a mitigation to only hand-out vanilla ORPorts for non-PT
enabled bridges is reasonable, but closing #7349 is the real solution since
I think this edge case is less likely to be hit than simply port scanning
suspected bridges which is only solvable by #7349.

The problems I see with closing #7349 are two-fold:
1) As Isis mentioned on IRC, it makes it easier for an attacker to spam the
BridgeAuth with fake bridge entries unless we start keeping the bridge auth
updated with new-PTs as they're developed to run test handshakes. This
might be painful depending on how frequently/quickly we add new PTs. #6396
will have to be re-thought for a ORPort-less bridge world.
2) #9366 shows one of the first issues you hit with an ORPort-less bridge:
there are numerous assumptions about relays having an ORPort enabled in the
source and in the specifications. Enumerating all of the affected locations
in the client/bridgeauth/directory(/other?) code and coming to a consensus
about what form the changes should take will require some work.

On Wed Dec 31 2014 at 12:06:19 AM David Fifield <david at bamsoftware.com>
wrote:

> On Wed, Dec 17, 2014 at 08:00:01PM -0800, David Fifield wrote:
> > Thanks, these are great results. You're right that disabling the ORPort
> > for PT bridges is the right solution. There are some technical obstacles
> > summarized in this ticket:
> >       "Obfsbridges should be able to 'disable' their ORPort"
> >       https://trac.torproject.org/projects/tor/ticket/7349
> > Basically, whatever tests bridges for reachability is ignorant of PTs,
> > so it only tries connecting to the ORPort. Since the bridge appears
> > unreachable, it doesn't go into BridgeDB to be handed out. So there are
> > a few different tasks that need to be unraveled to make it possible.
> >
> > The reachability testing also caused problems for us with obfs2/obfs3.
> > People would set up an obfsbridge, and obfsproxy would pick a random
> > port to listen on, and people didn't know that and so didn't open the
> > port on their firewall. There were a lot of bridges with a reachable
> > ORPort but unreacable obfsport. Because the ORPort was reachable, they
> > were in BridgeDB, even though they were useless as PT bridges.
> >
> > Having an easily findable ORPort definitely makes it easier for those
> > censors that do proactive or reactive scanning to find bridges. (Only
> > the GFW does reactive scanning as far as I know, and I haven't seen
> > evidence for or against proactive scanning like you did.) Even if the
> > ORPort is hidden on some random port, it still gives the censor a good
> > distinguisher for, say, suspected obfs3 streams: When you see something
> > that might be obfs3, scan all the other ports on the IP and see if you
> > find an ORPort.
>
> I thought of another angle to this, also related to #7349. Because it's
> impossible to run a PT bridge that both 1) hides its ORPort, and 2)
> appears in BridgeDB, that means that easily detectable ORPort
> connections can burn the IP, blocking the PT port in the process.
>
> Imagine this: you set up a nice obfs4 bridge. obfs4 is listening on port
> 20001, and the ORPort is on 45678. Because of #7349, you can't block the
> ORPort on 45678. Both ports end up in BridgeDB. People get your bridge
> when they request obfs4, and they are happy. But one day an innocent
> user requests a vanilla bridge, and connects to port 45678 using plain
> Tor. The connection is detected by the firewall, and the IP (and with it
> the obfs4 port) is blocked.
>
> The problem is that currently, PT⇒ORPort. So a censor that wants to
> block plain Tor and PTs, only really needs to be able to detect plain
> Tor, because it's always running on the same host a PT is running on.
> (I'm oversimplifying a bit: not always will the ORPort be handed out by
> BridgeDB.)
>
> Maybe I misunderstand something about how PublishServerDescriptor and
> BridgeDB work?
>
> David Fifield
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20141231/53cf87ae/attachment-0001.html>