...
|
...
|
@@ -1372,8 +1372,8 @@ the same geographic location.
|
1372
|
1372
|
<p>
|
1373
|
1373
|
Tor (like all current practical low-latency anonymity designs) fails
|
1374
|
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
|
|
1375
|
+example, suppose the attacker controls or watches the Tor relay you choose
|
|
1376
|
+to enter the network, and also controls or watches the website you visit. In
|
1377
|
1377
|
this case, the research community knows no practical low-latency design
|
1378
|
1378
|
that can reliably stop the attacker from correlating volume and timing
|
1379
|
1379
|
information on the two sides.
|
...
|
...
|
@@ -1381,31 +1381,34 @@ information on the two sides.
|
1381
|
1381
|
|
1382
|
1382
|
<p>
|
1383
|
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.
|
|
1384
|
+<i>C</i> relays. Suppose there are <i>N</i> relays total. If you select
|
|
1385
|
+new entry and exit relays each time you use the network, the attacker
|
|
1386
|
+will be able to correlate all traffic you send with probability
|
|
1387
|
+<i>(c/n)<sup>2</sup></i>. But profiling is, for most users, as bad
|
|
1388
|
+as being traced all the time: they want to do something often without
|
|
1389
|
+an attacker noticing, and the attacker noticing once is as bad as the
|
|
1390
|
+attacker noticing more often. Thus, choosing many random entries and exits
|
|
1391
|
+gives the user no chance of escaping profiling by this kind of attacker.
|
1392
|
1392
|
</p>
|
1393
|
1393
|
|
1394
|
1394
|
<p>
|
1395
|
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.
|
|
1396
|
+to use as entry points, and uses only those relays for her first hop. If
|
|
1397
|
+those relays are not controlled or observed, the attacker can't win,
|
|
1398
|
+ever, and the user is secure. If those relays <i>are</i> observed or
|
|
1399
|
+controlled by the attacker, the attacker sees a larger <i>fraction</i>
|
|
1400
|
+of the user's traffic — but still the user is no more profiled than
|
|
1401
|
+before. Thus, the user has some chance (on the order of <i>(n-c)/n</i>)
|
|
1402
|
+of avoiding profiling, whereas she had none before.
|
1403
|
1403
|
</p>
|
1404
|
1404
|
|
1405
|
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.
|
|
1406
|
+You can read more at <a href="http://freehaven.net/anonbib/#wright02">An
|
|
1407
|
+Analysis of the Degradation of Anonymous Protocols</a>, <a
|
|
1408
|
+href="http://freehaven.net/anonbib/#wright03">Defending Anonymous
|
|
1409
|
+Communication Against Passive Logging Attacks</a>, and especially
|
|
1410
|
+<a href="http://freehaven.net/anonbib/#hs-attack06">Locating Hidden
|
|
1411
|
+Servers</a>.
|
1409
|
1412
|
</p>
|
1410
|
1413
|
|
1411
|
1414
|
<p>
|
...
|
...
|
@@ -1413,7 +1416,8 @@ Restricting your entry nodes may also help against attackers who want
|
1413
|
1416
|
to run a few Tor nodes and easily enumerate all of the Tor user IP
|
1414
|
1417
|
addresses. (Even though they can't learn what destinations the users
|
1415
|
1418
|
are talking to, they still might be able to do bad things with just a
|
1416
|
|
-list of users.)
|
|
1419
|
+list of users.) However, that feature won't really become useful until
|
|
1420
|
+we move to a "directory guard" design as well.
|
1417
|
1421
|
</p>
|
1418
|
1422
|
|
1419
|
1423
|
<hr>
|