juanjo wrote: > 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? > > When I saw `CVE-2020*` combined with Hidden Service deanonymization in the title, I thought I'm going to have an interesting evening. Then I saw: This vulnerability is currently undergoing analysis and not all information is available. Please check back soon to view the completed vulnerability summary. I don't think this should be a CVE. First of all, it's not really deanonymization technically speaking. It's a 'Guard discovery attack'. Of course, it can potentially lead to onion service deanonymization if combined with another attack, so it's no secret this is quite possible. However, this is a well known problem. The onion service client (think of it as the visitor of a .onion website) is the one who chooses the rendezvous point. This means it can choose a hostile one, under his control, and at the same time run more middle relays and establish rendezvous circuits with a particular onion service continuously until a workable path from attacker's perspective is chosen. The rendezvous point being a part of the consensus or not does not actually make even the slightest difference. In fact, if we make a requirement for the rendezvous point to be in the consensus (from onion service server view of the network), we only end up with performance limitations. Because onion service client and onion service server can have (and often have) different views over the network. This is expected to aggravate if we want to really scale Tor (check walking onions proposal), so making this requirement will bottleneck Tor scaling without actually fixing the slightest thing. The only fix here is for Tor when running in onion service server mode to keep a track of its historic established rendezvous circuits and detect such attacks, because they are very trivial to detect: A Tor relay that is not on the consensus is unmeasured, so it can have a weight of n, thus a probability to be selected genuinely by a honest onion service client is n%. Now, you only look for insanely high n values. If your onion service server has 90% of its last "m" established rendezvous circuits to the same rendezvous point, you can't possibly think it's a coincidence right? Same logic applies to rendezvous relays that are in the consensus as well, only that you might allow a higher "n" value because you know their weights, and they might be fast relays. Thus in anyway your "n" cannot possibly be even near the limit an attacker needs to perform a guard discovery attack. I wrote a proposal sketch back in 2016 about this, it mitigates exactly this attack: https://lists.torproject.org/pipermail/tor-dev/2016-January/010291.html The protection is called "RendGuard" and is implemented in the Vanguards defense implemented by Mike Perry in 2018. The RendGuard part of that could be in Tor by default, because it doesn't face so many load-balancing issues and anti-fingerprinting issues as opposite to layer 2 and layer 3 guards.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev