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