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.<div><br></div><div>The problems I see with closing #7349 are two-fold:</div><div>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.</div><div>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.<br></div><br><div class="gmail_quote">On Wed Dec 31 2014 at 12:06:19 AM David Fifield <<a href="mailto:david@bamsoftware.com" target="_blank">david@bamsoftware.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Dec 17, 2014 at 08:00:01PM -0800, David Fifield wrote:<br>
> Thanks, these are great results. You're right that disabling the ORPort<br>
> for PT bridges is the right solution. There are some technical obstacles<br>
> summarized in this ticket:<br>
>       "Obfsbridges should be able to 'disable' their ORPort"<br>
>       <a href="https://trac.torproject.org/projects/tor/ticket/7349" target="_blank">https://trac.torproject.org/<u></u>p<u></u>rojects/tor/ticket/7349</a><br>
> Basically, whatever tests bridges for reachability is ignorant of PTs,<br>
> so it only tries connecting to the ORPort. Since the bridge appears<br>
> unreachable, it doesn't go into BridgeDB to be handed out. So there are<br>
> a few different tasks that need to be unraveled to make it possible.<br>
><br>
> The reachability testing also caused problems for us with obfs2/obfs3.<br>
> People would set up an obfsbridge, and obfsproxy would pick a random<br>
> port to listen on, and people didn't know that and so didn't open the<br>
> port on their firewall. There were a lot of bridges with a reachable<br>
> ORPort but unreacable obfsport. Because the ORPort was reachable, they<br>
> were in BridgeDB, even though they were useless as PT bridges.<br>
><br>
> Having an easily findable ORPort definitely makes it easier for those<br>
> censors that do proactive or reactive scanning to find bridges. (Only<br>
> the GFW does reactive scanning as far as I know, and I haven't seen<br>
> evidence for or against proactive scanning like you did.) Even if the<br>
> ORPort is hidden on some random port, it still gives the censor a good<br>
> distinguisher for, say, suspected obfs3 streams: When you see something<br>
> that might be obfs3, scan all the other ports on the IP and see if you<br>
> find an ORPort.<br>
<br>
I thought of another angle to this, also related to #7349. Because it's<br>
impossible to run a PT bridge that both 1) hides its ORPort, and 2)<br>
appears in BridgeDB, that means that easily detectable ORPort<br>
connections can burn the IP, blocking the PT port in the process.<br>
<br>
Imagine this: you set up a nice obfs4 bridge. obfs4 is listening on port<br>
20001, and the ORPort is on 45678. Because of #7349, you can't block the<br>
ORPort on 45678. Both ports end up in BridgeDB. People get your bridge<br>
when they request obfs4, and they are happy. But one day an innocent<br>
user requests a vanilla bridge, and connects to port 45678 using plain<br>
Tor. The connection is detected by the firewall, and the IP (and with it<br>
the obfs4 port) is blocked.<br>
<br>
The problem is that currently, PT⇒ORPort. So a censor that wants to<br>
block plain Tor and PTs, only really needs to be able to detect plain<br>
Tor, because it's always running on the same host a PT is running on.<br>
(I'm oversimplifying a bit: not always will the ORPort be handed out by<br>
BridgeDB.)<br>
<br>
Maybe I misunderstand something about how PublishServerDescriptor and<br>
BridgeDB work?<br>
<br>
David Fifield<br>
______________________________<u></u><u></u>_________________<br>
tor-dev mailing list<br>
<a href="mailto:tor-dev@lists.torproject.org" target="_blank">tor-dev@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" target="_blank">https://lists.torproject.org/<u></u>c<u></u>gi-bin/mailman/listinfo/tor-<u></u>de<u></u>v</a><br>
</blockquote></div>