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 <[email protected]> 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 > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev >
_______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
