...
|
...
|
@@ -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>
|