Tor block, or not Tor block?

A recent attempt to intercept Tor traffic has once again highlighted the challenges involved in trying to remain anonymous in a world full of well-resourced adversaries with a vested interest in matching your online activities to your real-world identity. The target this time was SIGAINT, an organization who provides “a public email service… to help journalists and activists combat the dragnet surveillance that exists on the Internet today.” Before we look at the attack, let’s look at what Tor is and how Tor Hidden Services work.
Tor derives from “The Onion Router”, a US Naval Research Laboratory project from the mid-1990’s which sought to provide ways for US intelligence operatives to communicate securely over untrusted networks. These days Tor consists primarily of two components: the Tor software running on a worldwide network of Internet servers, and a Tor client used to access sites through that network. The basic principle is that each node in the path between the Tor client and the destination server only knows who it received the packet from, and to whom it is sending the packet. The final hop in that path is an “Exit Node” which routes the packet normally across the Internet. Note that the Exit Node has no idea who the ultimate source of the packet was, it just knows to send any response back to the second last node, and so on. Despite some funding for research and development Tor is primarily a volunteer effort, especially when it comes to operating the various nodes which make up the Tor network – anyone can participate by installing and correctly configuring the Tor software on an Internet-connected host.
As well as providing anonymity for users browsing the public Internet, Tor also provides a way for people to host web sites within Tor itself, called “Hidden Services”. These are the addresses ending in .onion, such as Facebook’s Hidden Service located at https://facebookcorewwwi.onion. To access one of these sites you need to be connected to the Tor network, and provided you only access that site, your traffic will never leave Tor. SIGAINT also provided a .onion Hidden Service, but the thing about .onion addresses is that they are generated by a hashing algorithm, and so they tend to be difficult to remember. SIGAINT’s Hidden Service was located at http://sigaintevyh2rzvw.onion. To make it easier for Tor users to access the Hidden Service, they posted a link on their public Internet site, so a Tor user could browse to the easy-to-remember public site here, click the onion link, their browser would redirect to the .onion and now they’d be accessing their email totally within the safe anonymity of the Tor network. Sounds good? Actually, it turned out to be a terrible idea.
Here’s the problem – it meant that Tor users were clicking a link on a plain text HTML response which had transited an Exit Node, and not all of the people who participate in the Tor network are good guys. Specifically, someone had configured at least 70 Exit Nodes (6% of the total Exit Node pool at the time) to rewrite SIGAINT’s .onion link in the HTML response to a link which looked similar, but wasn’t the same, and which went to a completely different Hidden Service. That malicious Hidden Service acted as a reverse proxy to SIGAINT’s true Hidden Service, so any user who accessed their SIGAINT mailbox via the malicious service had very little idea that their activities were being monitored, by persons who at this stage are still unknown.
The Tor Project are well aware of the dangers posed by malicious Exit Nodes, and maintain a list of exits known to be bad and which are therefore prevented from handling user traffic. However, some of the malicious Exit Nodes were up for several weeks before the attack was detected, so an unknown number of SIGAINT users could have been placed at serious risk as a result. This attack was aided by the fact that SIGAINT were not using SSL on their public page, apparently in the belief that “…if it is a state-actor they could just use one of their CAs and mill a key”, but the attack also poses an interesting question for all web site operators to consider: should they block connections from Tor in order to protect any of their users who are Tor users from malicious Exit Nodes?
Most of the WAF customers I work with are intensely interested in understanding the nature of their incoming traffic, including how much is coming from Tor, but not all of them end up blocking those connections. As well as the obvious concerns around blocking legitimate users, there are larger questions around the nature of the Internet as we would like to see it. The more traffic there is flowing through Tor, the more difficult it is for adversaries to correlate traffic entering Tor with traffic exiting Tor, something which brings them much closer to matching a Real Live Person with the traffic they’ve generated. If we want an Internet where people can, for example, safely blow the whistle against powerful actors without risking their identity, then we need projects like Tor to succeed. But that’s not what I’m talking about here – rather than advocate for blocking all traffic coming from Tor, I’m suggesting that individual organizations might want to consider blocking certain types of Tor requests. If you’re a bank, you might decide that Tor users can browse your main web site but prevent access to an Internet banking login page. In addition, you should try to avoid putting your users in a position where they are surfing to your Hidden Service from a link on your main website, and if you can’t come up with an alternative way of publicizing your .onion, at least do it over SSL.
Ultimately, this latest incident suggests that organizations should be thinking about the services they will provide and how they will provide them to users coming from anonymity networks.