diff options
author | Roger Dingledine <arma@torproject.org> | 2012-06-12 06:32:01 -0400 |
---|---|---|
committer | Roger Dingledine <arma@torproject.org> | 2012-06-12 06:32:01 -0400 |
commit | 37c8237aafdb416507be0eeb8638ec0c9f01e5a4 (patch) | |
tree | 857321f1e62cae2bd04e910fbf1097da64332987 /proposals/188-bridge-guards.txt | |
parent | 0cc18bd0b5f7285f810206bd3ce28a856205e275 (diff) | |
download | torspec-37c8237aafdb416507be0eeb8638ec0c9f01e5a4.tar.gz torspec-37c8237aafdb416507be0eeb8638ec0c9f01e5a4.zip |
add in a point that rransom and i independently came up with
Diffstat (limited to 'proposals/188-bridge-guards.txt')
-rw-r--r-- | proposals/188-bridge-guards.txt | 8 |
1 files changed, 7 insertions, 1 deletions
diff --git a/proposals/188-bridge-guards.txt b/proposals/188-bridge-guards.txt index 3c53cfb..5a5a005 100644 --- a/proposals/188-bridge-guards.txt +++ b/proposals/188-bridge-guards.txt @@ -32,7 +32,7 @@ Status: Open same way clients do. This has been a known attack since early versions {XXXX check} of the design document; let's try to fix it. -2.1. Related ideas: Guard nodes +2.1. Related idea: Guard nodes The idea of guard nodes isn't new: since 0.1.1, Tor has used guard nodes (first designed as "Helper" nodes by Wright et al in {XXXX}) @@ -203,6 +203,12 @@ Status: Open from learning that we're a bridge... but another set of nodes will learn that anyway, so it's not clear what we'd gain. + One good reason to keep separate guard lists is to prevent the + *client* of the bridge from being able to enumerate the guards that + the bridge uses to protect its own traffic (by extending a circuit + through the bridge to a node it controls, and finding out where the + extend request arrives from). + 5. Other considerations What fraction of our traffic is bridge traffic? Will this alter |