If/when will LE support .onion addresses?

Alec Muffett's comment on how they got facebookcorewwwi:

http://archives.seul.org/tor/talk/Oct-2014/msg00433.html

[W]e [...] generated a bunch of keys with a fixed lead prefix ("facebook") and then went fishing looking for good ones.

I feel that we got tremendous[ly] lucky.

2 Likes

Sry, for the late reply, but this is an interesting question and I have no idea what the answer might be. But it may be better to direct that question to the Tor staff.

As for this thread in general: Are there any new news about .onion certs? Any other known standpoint/statement of a CA/B forum member?

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.

1 Like

The DV/EV issue you describe is exactly the same as in the "usual" web. Of course one can fake the address and also could get an DV cert, but would it matter?

I mean if you already visit the wrong (aka faked/malicious/phishing/...) onion site, it makes no difference whether you do this over HTTPS or HTTP.

That's why there are EV certs. And EV certs can be recognized and users must differentiate between them and only visit Facebook over onion if there is a EV bar for Facebook.
That's the same as in the usual web. So there is actually no difference in domain-faking, except one...

It is much harder to fake Onion names, because one has to use much processing power to e.g. just create facebookzuiajaiuo.onion. And this is still far way from the official Facebook onion domain and is gets exponentially harder with each character, so actually this risk is lower than in the "real" web.
Because in the real web you only have to find a bad domain registrar, which will "give" you the domain you want. There is no computing power needed.

Yeah, but you should not rely on the cert to see whether your website is "cheapsol4fueltkxg.onion or cheap4dsolwwloads.onion or maybe cheapsol4rmhmpl.onion". As the side is a cheap side the owner cannot afford to buy EV certs, so he used an DV cert. All other phishing domains do this too, but Tor users should be so clever to use bookmarks or other things to go to the correct address. I mean nobody can remember these addresses anyway.

From a cryptographic standpoint you cannot ignore this. That's a fact and if we would always ignore it we would not have to depreciate SHA-1 anyway.
That's why cryptographic things always assume there is an oracle.

but there’s one majro problem with EV certs for onion.

normal people cant get EVs

Again that’s no different to what the situation is for usual EV certs for “normal” domains. It also depends on how you define “normal” people. I think the only requirement for EV certs is a registered address (of a company or whatever is possible in the country where you get the cert) and - of course - the prove that the domain is yours.

EV baseline 8.5.1
https://cabforum.org/wp-content/uploads/EV-V1_5_9.pdf page 15
"The CA MAY only issue EV Certificates to Applicants that meet the Private Organization, Government Entity, Business Entity and Non-Commercial Entity requirements specified below"

so sadly no.

the main point being the only.
as far as I can trace it, MAY means that can can issue but dont need to, but with the only it means that IF they issue that they must adhere to the stuff said here.

in other words as an individual without any kind of company you can forget an EV and therefore HTTPS on onion

1 Like

In this case create your own small company… :wink:

yeah of course. nice joke.

a company means also having a bunch of obligations and all that just for an EV? well no.

It may depend on local laws. Here, I can form an LLC (Limited Liability Company) by filing a one-page form and paying a one-time filing fee of around $100. That's it, and no further upkeep is necessary. Sure, the filing fee is annoying, but the EV cert will cost you much more on an annual basis.

2 Likes

weall yeah but the whole EV thing is a bit annoying, especially when technically an OV would be enough because it mostly is the same as EV but iirc individuals can get an OV, and the identity checking of an individual would generate A LOT less cost for everyone

Just for completeness: Where is here? :smiley:

Edit: Found it. It's US.

OV and EV should be checked in a similar way.

At first: I think you mean OV.
Secondly: Do you really think so? I mean it is an "Organisation validated" cert...

That's not what commercial CAs want. They want money... :smile:

BTW: If this discussion continues an admin should split it into a separate topic...

oops edited. thx.

well OV does mean organization, but when you look around you can essentially get certs that dont have the company but you as the subject, they are mostly identical to ov but sometimes (startssl for example) they may be called IV (iidentity validation) but there are pretty equivalent to each other.

https://www.namecheap.com/support/knowledgebase/article.aspx/9470/68/can-i-get-an-ovev-certificate-if-i-apply-as-an-individual-and-dont-have-a-registered-organization

but I think OVs should be allowed for onions because locking individuals out of the system isnt gonna make the CA system any better.

Personally I’d say locking out any cert type is not going to make the system better…

but kicking DV into oblivion does actually make sense for onions. since the only thing that is checked for a theoretical onion DV is the onion key which is already used for encryption. so the main reason why someone would want to use HTTPS on an onion is more for the identity. than for encryption since the onion keys themselves are de facto DV because the onion name is a cut SHA1 ofthe onion key.

You might still want HTTPS to protect this outdated SHA-1 crypto more. It is essentially an additional layer of security, so it makes sense to use DV just for encryption

well I dunno the specifics of onion crypto but I thought it’s essentially RSA and that just the onion name is the truncated SHA1.
but the problem of DV onion is that the cert completely relies on the “outdated SHA-1 crypto” you say. if anyone can get a valid key for the same name they also can get a cert. and here we get to the heavily discussed point of HTTPS, locks and trust (where I personally think we should kick the locks out like it was dont in firefox 4-13)…

Indeed this could probably be made in Tor Browser for onion certs much earlier so that a usual DV cert does look like a HTTP connection currently looks and only OV/EV have a special handling.

HTTPS for onion is also important, because of one technical reason: More and more features browsers implement are only usable with HTTPS and a usual onion domain does not satisfy this requirement. So we can made a list of things onion domains cannot do if we cannot protect them with HTTPS:

Sadly, the onion addresses are too prone to cryptographic birthday attacks by design. Sure, it’s currently hard to generate such keys but that’s based on the assumption that the only method is a resource-hungry brute force attack. If someone were, however, to discover a method to exclude certain ranges or values, each targeted key would take much less resources. Instead of having to discover the target key itself, one would only need to find any key matching a partial string. For every character cut off, less resources are needed to find an matching key.