<div dir="ltr">The short answer is no, not much. The long answer is a lot longer than that, so get ready :P<br><br>This would serve the person intercepting the traffic in near exactly the same way it does the operator of the node - entry nodes know the client, middle nodes know the entry and exit nodes, exit nodes know the destination (and the traffic to that destination). You would still need to intercept a significant amount of nodes before being able to break anonymity and tell which users are responsible for what traffic - which is a problem because the entire reason this attack works is that it targets more specific IP blocks. That many announcements (for various nodes) would be pretty easy to see. If an attacker were able to intercept traffic on the entry and exit nodes, or the client and destination, they could use timing and bandwidth correlations to tell (with high probability) that this client is accessing this destination. But this is no different from an attacker with control of the entry node or exit/destination.<br>
<br>The only way to make use of it that doesn't involve guessing at what nodes are in use would be to start at one end and work backwards or forwards in realtime. Essentially, you start by intercepting traffic to a target destination, then intercept traffic to the exit node contacting that destination, then intercept traffic to the middle node contacting that exit, then the entry node contacting that middle node, and finally to the client. The problem here is that you'd need a consistant (and obvious) traffic pattern sustained throughout that time (which would be long, due to the large amount of traffic most nodes handle and that BGP is not instantaneous), which is not generally true of HTTP requests. The complexity of such an attack would be problematic, and it still involves quite a lot of guesswork.<br>
<br>So no, this isn't a significant risk to tor anonymity, it's at best a quicker way to intercept traffic and follow a node path to its source, and I would be amazed if that were pulled off successfully. Remember that this exploit only allows you to intercept traffic *to* a specific destination, and in that situation you have no more information than the real destination does (less, in fact, because you don't see the traffic going the other direction unless you intercept that too).<br>
<br clear="all">- John Brooks<br><br><div class="gmail_quote">On Thu, Aug 28, 2008 at 11:21 PM, F. Fox <span dir="ltr"><<a href="mailto:kitsune.or@gmail.com">kitsune.or@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<br>
Once I read about the recent BGP exploit (<br>
<a href="http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html" target="_blank">http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html</a> ) - which<br>
has the potential to re-route the traffic of millions of users - I had a<br>
question, from a theoretical standpoint:<br>
<br>
If such siphoning drew in traffic passing in between Tor nodes, would<br>
this have an effect on reducing anonymity for the users having their<br>
traffic relayed by these nodes? If so, how?<br>
<br>
- --<br>
F. Fox<br>
Owner of Tor node "kitsune"<br>
<a href="http://fenrisfox.livejournal.com" target="_blank">http://fenrisfox.livejournal.com</a><br>
<br>
Note 2008/08/19: I lost my old GPG keypair, and have generated a new<br>
one. Authenticity can be verified by checking the ContactInfo on kitsune.<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.9 (GNU/Linux)<br>
Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org" target="_blank">http://enigmail.mozdev.org</a><br>
<br>
iQIcBAEBCAAGBQJIt4dHAAoJECxKjnsrYHNHl8AP/3U3VKRjmft8SADOPJtOPdIt<br>
HCBbf60VSDTCPVnfKiDNQ7GmYDzUPeYX763qkPO6/yds/As6mwbIWYhtrMlGyX63<br>
0JhvWVnQdNDHQ2begsX4tHVJwck1+e3jCawoo9Z5uydKomJbPL3JNkxQ1RYQ5aKD<br>
sq1z5Ha27FpxB3kA9GjbcgrpIaQTCaBEY+vVtDtT+zQdmFSaBsWNuPhs/7Iq2Lum<br>
8AZwXMKElGIZICjMjf76Otdevkday40bgjPohliRfG9Yz5v5OHQLNI95GuI4YCxr<br>
aqLV7Q8aoqGEwkxkPYvBlMSV/F+0Q7Xwa9p+XgdSNtAhh4Q2dG7tdmOKPnOAEQzG<br>
1aKtFFFwKJgOK0YsvutB/l5ePgqv4WtM/CUHmcQViUT/1EwvgTDxOMV2MAwHAAmz<br>
TDSpnbgweWwbWy/BME76zECvJGJalOqXo2XOioKRGP2KAWjK4bQvtZaTvKCf3CVI<br>
cvJ/we8eQmqKRuBiFU6yQNcgzpx3Q5XMvyQi5FYB8X+HWH9oFNBSVFpN4jRVf0Dm<br>
RWNgx3XxejT1BzE7oRrQ19iAvT6q0jozhKayLbMWRlhE0NAeH9FuN7peAlS3CnGw<br>
MEWSEaS1xTxw3+vWUbWpJSisELqI19xkFWO5y7ThsoQGuCbMxZ4Zut0z8MVciQ2v<br>
yHquFwNAvmzRWYyOaamj<br>
=cnNg<br>
-----END PGP SIGNATURE-----<br>
</blockquote></div><br></div>