Step one is to look at the short and medium term answers that I described in the blog post on the topic.
I've asked Nick Hopper, a professor from Minnesota who is taking his sabbatical to work on Tor research problems, to think about the problem more deeply and see if there are good longer-term answers. Below are some of the ideas I suggested that he/we should explore.
We're definitely going to need help from the broader communities (research, hacker, social connections, etc) since we have our hands full teaching journalists what's going on with the NSA thing, making Tor work well when it's not under this much attack, etc. Please help!
But first, I should point out that the below ideas are for solving the current situation, where an enormous botnet has done a pretty good job at moving in without destroying its host. If he wanted to set his five million bots to trying to DDoS the Tor network, e.g. wasting the bandwidth of the volunteer relay operators, then that's a much crummier arms race to play. Five million bots is a lot of malicious hosts.
That said, here are some ideas to spark more thought. I was imagining breaking the ideas into three categories:
stuff we should do short-term that isn't too difficult;
stuff that isn't too tricky or risky that we should do medium term if the troubles remain; and
stuff we should do long-term if '1' and '2' don't work.
I think we have some handle on '1' (e.g. the points in the blog post), so I'm most interested in people to explore categories 2 and 3.
- Drop all requests that use the v3 link handshake, since 0.2.4 speaks the v4 handshake. Or drop all TAP handshake requests. That means Tor 0.2.3.25 (our current stable) would stop functioning; probably best to get 0.2.4.x out as stable first.
- Rate limiting of circuit creation, limiting differently by handshake class (I think this one's a near-term promising one but only if the bots never upgrade).
- Users have to solve some sort of captcha before they can make many circuits. Messy for headless users, and also messes up hidden services, and how exactly would we do it anyway? It seems like a lot of users think this is a great idea, but zero people have made any viable suggestions on how to do it engineering-wise.
- Consensus parameters to ask clients to back off of various behaviors (but when it comes down to it, if the client has an application request, and we've told it to back off, what should it do?)
- Which of the incentives design papers are suited for this situation? See Building Incentives into Tor, Recruiting New Tor Relays with BRAIDS, LIRA: Lightweight Incentivized Routing for Anonymity, and the related work section in each.
- Can we separate the hidden services functionality from normal Tor relays, and have it be an add-on that people use Tor relays for without Tor supporting the design explicitly? Would that actually help anything?
- Getting a sample of the malware, and contacting AV vendors to get them to help wipe it from the world.
- Using our social networks to try to track down the botnet operators and work with them to help them understand the harm they are doing.
- In the more crazy front: guards do passive OS fingerprinting (or heck, active nmaps) of the clients and throttle circuit requests and/or bandwidth from Windows users. Or they try to detect the pattern of circuit-building or accesses that the bot generates -- for example, if it's programmed to hit its hidden service every 20 minutes, then we can look for that pattern and treat
those clients specially.
This particular bot appears to just access a hidden service every so often. What would happen if they wanted to pass more traffic over the Tor network too? What are the right architecture / design changes for becoming robust to that attack, without impacting real users too much?
Also, it seems like the game theory changes dramatically if we assume the botnet operator will upgrade in response to our changes, or if we assume he won't. Maybe that's another way to categorize options. It also means that since the network is reasonably stable currently, and things could be a lot worse, then we should take our time and try to find some good long-term-viable solutions.
In summary, please help! I have better things to be doing than biting off this new research direction in parallel to all the others.