import EntryGuards faq entry
Roger Dingledine commited on 2011-02-05 07:04:03
Zeige 1 geänderte Dateien mit 55 Einfügungen und 0 Löschungen.
- docs/en/faq.wml 67e014d0f..69e025c44
| ... | ... |
@@ -79,6 +79,7 @@ |
| 79 | 79 |
<p>Anonymity and Security:</p> |
| 80 | 80 |
<ul> |
| 81 | 81 |
<li><a href="#KeyManagement">Tell me about all the keys Tor uses.</a></li> |
| 82 |
+ <li><a href="#EntryGuards">What are Entry Guards?</a></li> |
|
| 82 | 83 |
</ul> |
| 83 | 84 |
|
| 84 | 85 |
<p>Alternate designs that we don't do (yet):</p> |
| ... | ... |
@@ -1363,6 +1364,60 @@ the same geographic location. |
| 1363 | 1364 |
|
| 1364 | 1365 |
<hr> |
| 1365 | 1366 |
|
| 1367 |
+[https://www.torproject.org/docs/faq#EntryGuards Answer moved to our new FAQ page] |
|
| 1368 |
+ |
|
| 1369 |
+<a id="EntryGuards"></a> |
|
| 1370 |
+<h3><a class="anchor" href="#EntryGuards">What are Entry Guards?</a></h3> |
|
| 1371 |
+ |
|
| 1372 |
+<p> |
|
| 1373 |
+Tor (like all current practical low-latency anonymity designs) fails |
|
| 1374 |
+when the attacker can see both ends of the communications channel. For |
|
| 1375 |
+example, suppose the attacker is watching the Tor relay you choose |
|
| 1376 |
+to enter the network, and is also watching the website you visit. In |
|
| 1377 |
+this case, the research community knows no practical low-latency design |
|
| 1378 |
+that can reliably stop the attacker from correlating volume and timing |
|
| 1379 |
+information on the two sides. |
|
| 1380 |
+</p> |
|
| 1381 |
+ |
|
| 1382 |
+<p> |
|
| 1383 |
+So, what should we do? Suppose the attacker controls, or can observe, |
|
| 1384 |
+C relays. Suppose there are N relays total. If you select new entry and |
|
| 1385 |
+exit relays each time you use the network, the attacker will be able to |
|
| 1386 |
+correlate all traffic you send with probability (c/n)^2^. But profiling |
|
| 1387 |
+is, for most users, as bad as being traced all the time: they want to do |
|
| 1388 |
+something often without an attacker noticing, and the attacker noticing |
|
| 1389 |
+once is as bad as the attacker noticing more often. Thus, choosing many |
|
| 1390 |
+random entries and exits gives the user no chance of escaping profiling |
|
| 1391 |
+by this kind of attacker. |
|
| 1392 |
+</p> |
|
| 1393 |
+ |
|
| 1394 |
+<p> |
|
| 1395 |
+The solution is "entry guards": each user selects a few relays at random |
|
| 1396 |
+to use as entry points, and uses only those relays for entry. If those |
|
| 1397 |
+relays are not controlled or observed, the attacker can't win, ever, |
|
| 1398 |
+and the user is secure. If those relays *are* observed or controlled |
|
| 1399 |
+by the attacker, the attacker sees a larger _fraction_ of the user's |
|
| 1400 |
+traffic -- but still the user is no more profiled than before. Thus, |
|
| 1401 |
+the user has some chance (on the order of (n-c)/n) of avoiding profiling, |
|
| 1402 |
+whereas she had none before. |
|
| 1403 |
+</p> |
|
| 1404 |
+ |
|
| 1405 |
+<p> |
|
| 1406 |
+You can read a bit more at http://freehaven.net/anonbib/#wright02, |
|
| 1407 |
+http://freehaven.net/anonbib/#wright03, or |
|
| 1408 |
+http://freehaven.net/anonbib/#hs-attack06. |
|
| 1409 |
+</p> |
|
| 1410 |
+ |
|
| 1411 |
+<p> |
|
| 1412 |
+Restricting your entry nodes may also help against attackers who want |
|
| 1413 |
+to run a few Tor nodes and easily enumerate all of the Tor user IP |
|
| 1414 |
+addresses. (Even though they can't learn what destinations the users |
|
| 1415 |
+are talking to, they still might be able to do bad things with just a |
|
| 1416 |
+list of users.) |
|
| 1417 |
+</p> |
|
| 1418 |
+ |
|
| 1419 |
+ <hr> |
|
| 1420 |
+ |
|
| 1366 | 1421 |
<a id="EverybodyARelay"></a> |
| 1367 | 1422 |
<h3><a class="anchor" href="#EverybodyARelay">You should make every Tor |
| 1368 | 1423 |
user be a relay.</a></h3> |
| 1369 | 1424 |