[tor-dev] Timing of opening pre-emptive circuits?

[Jeremy Rand]

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 at 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 at veclabs.net is having technical issues at the
moment.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20190920/46fc44e7/attachment.sig>