It is statistically improbable that there would ever be two services with the same onion address. We rely on ignoring such improbabilities all the time, both in computing (e.g. what if somehow you get bad luck and all your memory accesses are cache line collisions, suddenly the PC goes thousands of times slower for no apparent reason, this never happens) and in real life (e.g. what if all the Oxygen molecules in the room youâre in migrate randomly to the corners, leaving you to mysteriously suffocate, again this is so improbably it never actually happens though it theoretically could)
What is NOT unlikely is for a service to be intentionally created with an onion address that, to a human, looks similar to another address. This is already a problem to some extent on the public Internet anyway, hsbc.co.uk has to expect that bad guys will make similar-looking sites named hbsc.co.uk and so on. Typo-squatting of auto-installed Node.js code has been tried too. On the Internet the Registries are in a position to prohibit this sort of thing. But for Tor there is no Registry function, the names are gibberish because they arenât handled by a central registry.
So that means if you have a popular Tor hidden service nothing stands in the way of me creating a hidden service with a very similar looking name. With DV, nothing stands in the way of me getting a certificate issued for that name. Now my service looks exactly as genuine as yours and there is nothing any authority can do about it except that a CA could (but Letâs Encrypt is on record as saying they want to avoid this because itâs a slippery slope) revoke the certificate for the misbehaviour of its subject.
With EV thereâs a way to know whatâs real out of band from Tor. If I know I want the famous social network Facebook, a site with a plausible looking onion address but an EV certificate for âRandyâs Kitchen Suppliesâ wonât fool me. But with DV Iâm often left to try to guess whether the site I wanted was cheapsol4fueltkxg.onion or cheap4dsolwwloads.onion or maybe cheapsol4rmhmpl.onion âŚ
So itâs tricky. While the little padlocks remain mistakenly over-trusted by ordinary web users itâs easy to see why CA/B is shy of allowing DV for onion addresses.
One option open to the really pro-Tor people is to vote with your feet. Set up a non-CAB compliant CA, maybe run on Tor itself, and have it use ACME to verify only .onion names and issue DV certificates trusted by other Tor users and particularly the Tor browser. The CA/B wasnât given its power by some omniscient power or even by a government, so if Tor users decide en masse that they want their own rules collectively, thatâs what will happen. But it doesnât work if just a dozen people do this, it has to be a real popular movement.
As CA/B members, Letâs Encrypt canât be that new CA and probably they donât especially want to be. Their Boulder CA software and lots of know-how are public though for somebody else to get into the game.