-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
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, - -- - -Jeremy Rand Lead Application Engineer at Namecoin Mobile email: jeremyrandmobile@airmail.cc 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@veclabs.net is having technical issues at the moment.
Hi Tor-Dev,
I'm curious what the timing is of Tor's opening of preemptive circuits. Specifically, consider the following attack:
- A new stream is assigned to a clean circuit.
- Because of the above, that clean circuit is now a dirty circuit.
- 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
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 ;)
s7r:
Hi Tor-Dev,
I'm curious what the timing is of Tor's opening of preemptive circuits. Specifically, consider the following attack:
- A new stream is assigned to a clean circuit.
- Because of the above, that clean circuit is now a dirty circuit.
- 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.
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 -
s7r