If/when will LE support .onion addresses?

Feature Requests
36

but then the issue is the illusuion of security to the not so technically intrested people.

point 9is even though weak security is better than none if a weak security isnt properly shown to the user it gives the impression it’s more secure than it actually is, which is also the reason why RC4 is disabled in many browsers (exccept firefox which actually asks to “load page with outdated crypto” before actually loading the page)

also an intresting point is that Firefox kicked the lock icon into oblivion in version 4 (even though it reappeared in version 14) because the lock always leaves the impression it’s perfectly secure and stuff while the Green EV bar was not that popular at the time and/or that banks and other stuff mostly pointed out “look for the lock” and that remained in the memory.
way back when certificates were a lot more expensive that was true because SSL certificates were a lot more expensive (well obvious) which for one point lowers the number of attackers that will even try that approach and not to forget that SSL Certs back then had way higher validation standards which are pretty similar to EVs today.

that’s the part where the Identity bar from back then comes in. it either listed the entity name for EVs or the domain name for DV/OV certs, which also makes it easier to discern these attacks where an attacker uses a really long subdomain which looks like a path. because even if the user did not look for the green bar it was pretty obvious from the identity bar that it was not your bank site.

a development of the browsers that made stuff actually worse is how chrome and FF do the lock handling. I dont know since when chrome always uses green locks but Firefox iirc does it since version forty-something, I am not sure. IN MY OPINION, green is a color that should be reserved for EVs and it should use another color for DVs like grey which was used before, or the blue from the identity bar in FF versions 4-13. the even more intresting part is that actually microsoft (the company which had the worst browser for a long time, as seen by their standard support) actually implemented grey, hollow locks for DV/OV certs in more recent versions of Edge, why I dont actually understand the point of making it hollow because the encryption is actually not weaker than EV, but just the verification, which is the point of the lock losing its green color.

37

@rugk Do you known what happen is 2 tor hidden services have the same onion address ?
Someone requesting that address goes to one of the hidden service randomly ?

@schoen Depending of the behaviour of tor on my previous question, to impersonate an onion address, one can just need CPU power to generate a collision (on 80-bit). I think this can be a lot easier for a lot of persons that doing a MiTM attack on http-01 or tlsni-01 or a dns poisoning on dns-01 for the ACME server. Just rent a amazon EC2 for CPU power.

38

Seems like a bit of a large "just" to me: if we imagine that testing a candidate key for a desired collision is about as hard as computing a candidate Bitcoin block, this amount of computation would take the entire Bitcoin network -- which is almost 100% custom ASICs now, not even GPUs -- two weeks. (I'm not suggesting that the Bitcoin network itself can perform this computation, just using it as a point of comparison.)

1 Like
39

The thing is that this isn’t just a theoretical attack, Facebook managed to get facebookcorewwwi.onion for their hidden service. I don’t know about the i and possibly the www at the end but the rest of that looks like it was targeted.

Now the average attacker won’t have the CPU resources of Facebook, but most hidden service providers don’t either so only fix the start of their address. In this case getting an exact collision is hard but getting the fixed part and hoping to catch typos is easy, the user is unlikely to notice this as being random makes the end part hard to remember.

40

It gets exponentially more difficult to choose each individual character. Facebook has been clear that the "corewwwi" was not targeted by their search (they only looked for names beginning in "facebook"); they found a large number of names beginning with "facebook" and then chose to use one that was memorable and pronounceable. They've insisted that they were lucky that this one is so memorable and so pronounceable, but in any case they weren't aiming for it. (Getting "facebookcorewwwi" specifically is literally a trillion times more work than getting a single onion name that starts with "facebook".)

For the reasons you describe, users of hidden services should never trust purported links simply because their targets look visually familiar; they need to be sure that the entire site name is exactly correct. However, that doesn't really affect the propriety of issuing TLS certificates for these names.

3 Likes
41

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
42

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?

43

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
44

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.

45

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

normal people cant get EVs

46

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.

47

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
48

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

49

yeah of course. nice joke.

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

50

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
51

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

52

Just for completeness: Where is here? :smiley:

Edit: Found it. It's US.

53

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...

54

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.

55

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