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

[David Fifield]

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