Re: [tor-dev] CVE-2020-8516 Hidden Service deanonymization

[George Kadianakis <desnacked@xxxxxxxxxx>]

David Goulet <dgoulet@xxxxxxxxxxxxxx> writes:

> On 04 Feb (19:03:38), juanjo wrote:
>
> Greetings!
>
>> Since no one is posting it here and talking about it, I will post it.
>> 
>> https://nvd.nist.gov/vuln/detail/CVE-2020-8516
>> 
>> The guy: http://www.hackerfactor.com/blog/index.php?/archives/868-Deanonymizing-Tor-Circuits.html
>> 
>> Is this real?
>> 
>> Are we actually not verifying if the IP of the Rend is a node in the Tor
>> network?
>
> We (network team) actually don't think this is a bug but it is actually done
> on purpose for specific reasons. Please see asn's answer on
> https://bugs.torproject.org/33129 that explains why that is.
>
> Onto the bigger issue at ends that the post explains. I'm going to extract the
> relevant quote that this post is all about:
>
>     Remember: the guard rarely changes but the other two hops change often.
>     If he can repeatedly map out my circuit's last node, then he can build a
>     large exclusion list. If he can exclude everything else, then he can find
>     my guard node. And if he can't exclude everything, then he can probably
>     whittle it down to a handful of possible guard nodes.
>
> That is indeed a known attack. One can create a set of relays from the 3rd
> node (last one before connecting to the rendezvous point) selected by the
> service and doing enough requests to the service, you can end up with a very
> large set of relays that can _not_ be your Guard due to how path selection
> works as explained in the blog post.
>

For what it's worth, I'm glad this discussion has been restarted because
we did lots of research work in 2018 about these sort of attacks, but we
were kinda drown in the various tradeoffs and ended up not doing much
after releasing the vanguard tool.

For people who are following from home and would like to help out here
is some reading materials:
   https://lists.torproject.org/pipermail/tor-dev/2018-April/013070.html
   https://lists.torproject.org/pipermail/tor-dev/2018-May/013162.html
   https://trac.torproject.org/projects/tor/ticket/25754

Basically, from what I remember, to defend against such attacks we
either need to change our path selection logic (#24487), or abandon the
path restrictions that cause infoleaks (big thread above), or use two
guards (prop#291 plus big thread above). Each of these options has its
own tradeoffs and we need to analyze them again. If someone could do a
summary that would be great to get this started again...

For now, if you are afraid of such attacks, you should use and love vanguards!

Thanks a lot! :-)
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev