s7r: >> Hi Tor-Dev, >> >> I'm curious what the timing is of Tor's opening of preemptive circuits. >> Specifically, consider the following attack: >> >> 1. A new stream is assigned to a clean circuit. >> 2. Because of the above, that clean circuit is now a dirty circuit. >> 3. Because of the above, the number of clean circuits is now decreased >> by 1. >> 4. Because of the above, the number of clean circuits is now lower than >> the number that Tor wants to have open. >> 5. Because of the above, Tor opens a new preemptive circuit. >> 6. An attacker who can observe the circuit in (1) and the circuit in (5) >> can deduce by temporal proximity that those 2 circuits belong to the >> same client. >> >> This attack seemed obvious enough to me that I assumed that Tor must >> have some kind of countermeasure to it, e.g. random delays in opening >> preemptive circuits. However, the tor-path specification doesn't >> mention any such countermeasure, and based on a brief search through the >> Tor source code, all I can find is that Tor opens preemptive circuits >> using a function that always gets called once per second (with no >> mention of any delay beyond that one-second interval, random or >> otherwise). >> >> So, does Tor make any effort to mitigate the above attack? If so, what >> mitigations are present, and where would I find them (in both the spec >> and the source code)? If not, is there any documented reason (e.g. "the >> attack is too hard to pull off" or "we want to mitigate it but haven't >> gotten to it yet") for the lack of mitigation? >> >> Cheers, > > > Hi Jeremy, > > When I read your checklist from 1 to 6 I remembered that there was a > research made on this [1] (I think you are talking about the same thing, > except not mentioning where your "attacker" is positioned). If a counter > measure existed it would have been documented in the Tor spec for > tor-path of course, so I guess that part is correct. > > There is an obvious straight forward solution to fix it [2], except > AFAIK nobody had time to work on this yet. > > I guess this is because this threat is not very scary, it is nice to fix > it of course, but correlating anonymous circuits to the same anonymous > user is much less scary than: > - guard discovery attack; > - guard partitioning attacks / path-bias attacks; > - routers netflow recording of traffic patterns; > - v3 onion services; > > There has been a lot of work into these directions. > > [1]: > https://lists.torproject.org/pipermail/tor-dev/2014-September/007517.html > > [2]: > https://lists.torproject.org/pipermail/tor-dev/2014-September/007518.html That's great info, thanks for the references! > If this thread model is interesting to you or your project(s), you can > take Paul's ideas from [2] and write a patch. It is also going to need a > proposal before it will be merged into Tor but at least there will be > some action ;) At this time it's unlikely that I'll have free time to write a patch, especially as this is someone outside of my area of expertise. That said, this does seem like something that would be beneficial to patch, so I certainly do hope someone volunteers to do it. (Maybe me in the distant future.) Cheers, -- -Jeremy Rand Lead Application Engineer at Namecoin Mobile email: jeremyrandmobile@xxxxxxxxxx Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C Send non-security-critical things to my Mobile with OpenPGP. Please don't send me unencrypted messages. My business email jeremy@xxxxxxxxxxx is having technical issues at the moment.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev