Re: [tor-dev] Internet-wide scanning for bridges

[David Fifield <david@xxxxxxxxxxxxxxx>]

On Fri, Dec 12, 2014 at 04:33:05PM -0800, Vlad Tsyrklevich wrote:
> Hello, while taking a looking at TorCloud I it used static OR and obfs2+obfs3
> ports making them trivial to discover by scanning EC2's IP address space. This
> led me to consider the more general attack of internet-wide scanning to
> discover Tor bridges. Most Tor relays run their ORPorts on port 443 or 9001 so
> I began investigating there.
> 
> I began by looking at Project Sonar's port 443 SSL certificate database looking
> for certificates matching the tor certificate pattern. In talking with Eric
> Wustrow about ZMap, I discovered that he and the other ZMap authors had already
> published about this attack in their original paper. Eric mentioned that in his
> discussion with Roger that the response to the attack was going to be the
> soon-to-be-deployed obfuscated transports which were intended to be run on
> random high ports; however, the eventual roll out of obfsproxy did not change
> the fact that bridge's ORPorts continue to be publicly accessible.
> 
> While I was analyzing Internet-wide survey-data for port 443 and 9001
> (helpfully provided by Project Sonar/H D Moore) I found the Onionoo data set. I
> was able to quantify the impact of the attack using the Onionoo data and verify
> it using the ZMap scans. There are 4267 bridges, of them 1819 serve their
> ORPort on port 443 and 383 serve on port 9001. That's 52% of tor bridges. There
> are 1926 pluggable-transports enabled bridges, 316 with ORPort 443 and 33 with
> ORPort 9001. That's 18% of Tor bridges. 203 (64%) of PT-enabled bridges with
> ORPort 443 were TorCloud. I was able to approximately verify these figures
> using the Internet-wide scans. By grabbing bridge's certificates and
> calculating their hashed fingerprint I realized I was also discovering a fair
> amount of private bridges not included in the Onionoo data set.
> 
> Eliminating the ORPort entirely for PT-enabled bridges seems like the ultimate
> solution to this attack, but the implications of such a change are unclear to
> me. Another change to mitigate this issue is changing the behavior of ports
> specified as 'auto' and then changing defaults and documentation to use auto by
> default. Currently specifying 'auto' in your torrc lets the OS decide the port;
> however, if tor were to generate a random port on first use that it continued
> to use across restarts it would it possible to use this for ORPorts and
> pluggable transports by default (as opposed to the current situation where for
> bridges you want ORPort auto but constant PT ports and a constant ORPort for
> relays which is confusing.)

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. Bridges that are easy to scan for aren't totally
useless, because they still work in places where the censor isn't as
sophisticated---like the default Tor Browser bridges, which are easily
blockable because their addresses are hardcoded in the source code, but
for whatever reason aren't blocked in many places that censor vanilla
Tor.

I wouldn't say that it's always a mistake for a bridge to be running on
443. Sometimes you need it to get through a firewall. And then it
depends on the censor's capabilities, whether you want vanilla Tor on
443 or obfs3 on 443. Vanilla Tor is fingerprintable as Tor, but it is at
least TLS; while obfs3 doesn't look like Tor but doesn't look like TLS
either. One configuration might get past a censor that blacklists Tor;
the other might get past one that whitelists TLS. But I think you're
right, that a lot more people are exposing ORPorts on 443 or 9001 than
are aware.

David Fifield
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev