|
@@ -3,10 +3,12 @@
|
|
|
- Try to leak less information about what relays a client is
|
|
|
choosing to a side-channel attacker. Previously, a Tor client
|
|
|
would stop iterating through the list of available relays as
|
|
|
- soon as it had chosen one, thus leaking information about which
|
|
|
- relays it picked for a circuit to a timing attack. (Tor is
|
|
|
- likely to still leak information about which relays it has
|
|
|
- chosen for a circuit to other processes on the same computer,
|
|
|
- through e.g. which cache lines it loads while building the
|
|
|
- circuit.)
|
|
|
-
|
|
|
+ soon as it had chosen one, thus finishing a little earlier
|
|
|
+ when it picked a router earlier in the list. If an attacker
|
|
|
+ can recover this timing information (nontrivial but not
|
|
|
+ proven to be impossible), they could learn some coarse-
|
|
|
+ grained information about which relays a client was picking
|
|
|
+ (middle nodes in particular are likelier to be affected than
|
|
|
+ exits). The timing attack might be mitigated by other factors
|
|
|
+ (see bug #6537 for some discussion), but it's best not to
|
|
|
+ take chances. Fixes bug 6537; bugfix on 0.0.8rc1.
|