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

[s7r]

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.

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