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@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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev