commit fb7c47262f60f1c75108512305e37c89b0418fa1 Author: Nick Mathewson <nickm@torproject.org> Date: Mon Feb 2 08:36:39 2015 -0500 Add 241-suspicious-guard-turnover.txt --- proposals/000-index.txt | 2 + proposals/241-suspicious-guard-turnover.txt | 174 +++++++++++++++++++++++++++ 2 files changed, 176 insertions(+) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index b8d4490..b6c7415 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -161,6 +161,7 @@ Proposals by number: 238 Better hidden service stats from Tor relays [DRAFT] 239 Consensus Hash Chaining [DRAFT] 240 Early signing key revocation for directory authorities [DRAFT] +241 Resisting guard-turnover attacks [DRAFT] Proposals by status: @@ -186,6 +187,7 @@ Proposals by status: 238 Better hidden service stats from Tor relays 239 Consensus Hash Chaining 240 Early signing key revocation for directory authorities + 241 Resisting guard-turnover attacks NEEDS-REVISION: 131 Help users to verify they are using Tor 190 Bridge Client Authorization Based on a Shared Secret diff --git a/proposals/241-suspicious-guard-turnover.txt b/proposals/241-suspicious-guard-turnover.txt new file mode 100644 index 0000000..a0313b2 --- /dev/null +++ b/proposals/241-suspicious-guard-turnover.txt @@ -0,0 +1,174 @@ +Filename: 241-suspicious-guard-turnover.txt +Title: Resisting guard-turnover attacks +Author: Aaron Johnson, Nick Mathewson +Created: 2015-01-27 +Status: Draft + +1. Introduction + + Tor uses entry guards to prevent an attacker who controls some + fraction of the network from observing a fraction of every user's + traffic. If users chose their entries and exits uniformly at + random from the list of servers every time they build a circuit, + then an adversary who had (k/N) of the network would deanonymize + F=(k/N)^2 of all circuits... and after a given user had built C + circuits, the attacker would see them at least once with + probability 1-(1-F)^C. With large C, the attacker would get a + sample of every user's traffic with probability 1. + + To prevent this from happening, Tor clients choose a small number + of guard nodes (currently 1: see proposal 236). These guard nodes + are the only nodes that the client will connect to directly. If + they are not compromised, the user's paths are not compromised. + + But attacks remain. Consider an attacker who can run a firewall + between a target user and the Tor network, and make + many of the guards they don't control appear to be unreachable. + Or consider an attacker who can identify a user's guards, and mount + denial-of-service attacks on them until the user picks a guard + that the attacker controls. + + In the presence of these attacks, we can't continue to connect to + the Tor network unconditionally. Doing so would eventually result + in the user chosing a hostile node as their guard, and losing + anonymity. + + + + +2. Proposed behavior + + Keep a record of all the guards we've tried to connect to, + connected to, or extended circuits through in the last PERIOD + days. + + (We have connected to a guard if we authenticate its identity. + We have extended a circuit through a guard if we built a + multi-hop circuit with it.) + + If the number of guards we have *tried* to connect to in the last + PERIOD days is greater than CANDIDATE_THRESHOLD, do not attempt + to connect to any other guards; only attempt the ones we have + previously *tried* to connect to. + + If the number of guards we *have* connected to in the last PERIOD + days is greater than CONNECTED_THRESHOLD, do not attempt to + connect to any other guards; only attempt ones we have already + *successfully* connected to. + + If we fail to connect to NET_THRESHOLD guards in a row, conclude + that the network is likely down. Stop/notify the user; retry + later; add no new guards for consideration. + + [[ optional + If we notice that USE_THRESHOLD guards that we *used for + circuits* in the last FAST_REACT_PERIOD days are not working, but + some other guards are, assume that an attack is in progress, and + stop/notify the user. + ]] + +2.1. Suggested parameter thresholds. + + PERIOD -- 60 days + + FAST_REACT_PERIOD -- 10 days + + CONNECTED_THRESHOLD -- 8 + + CANDIDATE_THRESHOLD -- 20 + + NET_THRESHOLD -- 10 (< CANDIDATE_THRESHOLD) + + [[ optional + USE_THRESHOLD -- 3 (< CONNECTED_THRESHOLD) + ]] + (Each of the above should have a corresponding consensus parameter.) + +2.2. What do we mean by "Stop/warn"? + + By default, we should probably give warnings in most of the above + cases for the first version that deploys them. We can have an + on/off/auto setting for whether we will build circuits at all if we're + in a "stopped" mode. Default should be auto, meaning off for now. + + The warning needs to be carefully chosen, and suggest a workaround + better than "get a better network" or "clear your state file". + +2.3. What's with making USE_THRESHOLD optional? + + Aaron thinks that getting rid of it might help in the fascistfirewall + case. I'm a little unclear whether that makes any of the attacks + easier. + +3. State storage requirements + +Right now, we save for each guard that we have made contact with: + + ID + Added + is dircache? + down-since + last-attempted + bad-since + chosen-on-date, chosen-by-version + path bias info (circ_attempts, successes, close_success) + +To implement the above proposal, we'll need to add, for each guard +*or guard candidate*: + when did we first decide to try connecting to it? + when did we last do one of: + decide to try connecting to it? + connect to it? + build a multihop circuit through it? + which one was it? + +Probably round these to the nearest day or so. + +4. Future work + + We need to make this play nicely with mobility. When a user has + three guards on port 9001 and they move to a firewall that only + allows 80/443, we'd prefer that they not simply grind to a halt. If + nodes are configured to stop when too many of their guards have gone + away, this will confuse them. + + If people need to turn FascistFirewall on and off, great. But if + they just clear their state file as a workaround, that's not so good. + + + If we could tie guard choice to location, that would help a great + deal, but we'd need to answer the question, "Where am I on the + network", which is not so easy to do passively if you're behind a + NAT. + + + +Appendix A. Scenario analysis + +A.1. Example attacks + + * Filter Alice's connection so they can only talk to your guards. + + * Whenever Alice is using a guard you don't control, DOS it. + +A.2. Example non-attacks + + * Alice's guard goes down. + + * Alice is on a laptop that is sometimes behind a firewall that + blocks a guard, and sometimes is not. + + * Alice is on a laptop that's behind a firewall that blocks a lot + of the tor network, (like, everything not on 80/443). + + * Alice has a network connection that sometimes turns off and turns + on again. + + * Alice reboots her computer periodically, and tor starts a little + while before the network is live. + +Appendix B. Acknowledgements + + Thanks to Rob Jansen and David Goulet for comments on earlier versions of + this draft. +