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