wait a sec, this doesnt make sense, I dont think that that many companies use Tor and, but rather more "normal" people, now you can guess three times who may NOT recieve an EV cert...
Agreed, however, times change. The .onion domain is growing far more legitimate every day. The desire for end-to-end encryption, privacy and anonymity will only increase as dragnet government surveillance grows ever more intrusive.
At some point this will need to be supported, and without the āspecial useā designation.
I value the letsencrypt.org project immensely and hope that they will find a way to make this work.
well it should be but some stupid āforumā (not pointing names, but it should be obvious) said that only companies and stuff may use those with HTTPS.
Hi @Lelantos, itās not really a question of software features (or about Letās Encrypt not caring about the issue), itās a question of CA/Browser Forum rules that .onion certs may currently only be EV, which Letās Encrypt doesnāt do. If these rules change (which several people from LE have said we hope they will), we would be interested in exploring whether we could issue .onion certs.
Please see the just-posted item at
for more about this issue.
4 Likes
but why did they say EV only and essentially locked out normal people, and why can normal ppl not get EV certs this is discrimination, I say! (not by LE, obviously but by the forum)
Increasingly we can envisage more practical use cases for .onion certificates.
- https://emerproxy.xyz - (with Letās Encrypt 4096-bit SSL), allows resolution of ā new ā TLDās using OpenNIC project DNS
We consider allowing access via a .onion / SSL enabled Tor hidden_service for resolution of OpenNIC TLDās (through Tor Browser) including;
Emercoin - .emc, .coin, .lib, .bazar - http://emercoin.com/EMCDNS_and_NVS
Namecoin - .bit
New Nations - .uu, .ti, .te, .ku
Open NIC - .bbs, .dyn, .free, .fur, .geek, .gopher, .indy, .ing, .micro, .neo, .null, .oss, .oz, .parody
It is infeasible for every Tor .exit to resolve the above domains. Thus, the only realistic solution (for increased anonymity, privacy and security for the user) is to provide an SSL enabled Tor hidden_service proxy.
However, said encrypted hidden_service, as a web proxy, also effectively provides access to clearnet i.e. a āhidden_serviceā that is not hidden and a Tor .exit node that is not listed as a Tor network .exit node.
Something towards the new ā Internet of things ā ā Letās ā Encrypt all the things ā ā¦
and thank you for the existing domain certificate. 
Hello. My understanding is that OpenNIC and New Nations domains as wall as Namecoin and Emercoin are not recognized by ICANN, so it is unlikely for CA/B forum to allow the issuance of certificates for these TLDs. .onion is a special case where it has been approved as a Special-Use domain.
Indeed. Being aware of this and realizing that the best prospect for secure, private and increased anonymous access for ā alternative ā TLDās (for now) is probably only through an SSL enabled .onion domain as a hidden_service to clearnet proxy service, as described above.
So, .onion support by Letās Encrypt would be a massive and important move forward in many regards.
I (we) can approve this notion, even if ICANN cannot. 
the problem is that as far as I know the forum said that for .onion you can only get EV, which LE doesnt do.
@My1, I believe thatās still correct and weāre going to have to ask about it in the future. Of course, we may also have users wanting us to figure out a solution for safely supporting internationalized domain names before we begin to worry about .onion names!
1 Like
I wonder why the cab said only EV for onion and therefore locking out normal people?
You can read their old discussions about it on the cabfpub list, I think.
I believe the basic idea was that only one member CA was planning to issue .onion certs and they were only expecting to do it with fully-identified customers, and this was seen as reducing risk of any kind of misissuance or ambiguity.
1 Like
yeah but that can be done via OV as well or create another exception in appendix F (or wherever the onion stuff is) so normal people can use SSL or onion.
FYI according to Cloudflare there really seems to be a (IMO understandable, but disputable) reason why the CA/B forum did only allowed EV certs:
The problem is generating SSL certificates to encrypt traffic to the .onion sites. Tor uses hashes generated with the weak SHA-1 algorithm to generate .onion addresses and then only uses 80 bits of the 160 bits from the hash to generate the address, making them even weaker. This creates a significant security risk if you automatically generate SSL certificates. An attacker could generate a site that collides with the 80-bit .onion address and get a certificate that could be used to intercept encrypted traffic.
Because of this risk, the CA/B Forum, which regulates the issuance of SSL certificates, requires certificates for .onion addresses to be EV certificates.
They continue:
The solution is for the Tor Project to support a stronger hashing algorithm, such as SHA256, for .onion addresses. With that in place, we believe the CA/B Forum would be open to discussing the automatic issuance of certificates.
1 Like
@rugk, thatās an interesting observation. Hopefully soon we can get some concrete views from other CA/B Forum members about whether thatās still a concern for them.
I think this observation makes sense at one level ā thereās a cryptographic security mismatch between different things and so the overall level of security provided would apparently be weaker than a relying party might expect ā but on the other hand, almost all DV is done using completely non-cryptographic mechanisms and by checking unsigned data! So checking cryptographically-signed data using an 80-bit hash prefix is a stronger validation than, say, just doing a DNS or whois lookup and accepting the unsigned results (which is the basis for security for almost all DV today, with the exception of the minority of domains that are DNSSEC-signed).
This argument seems akin to saying āoh no, this personās PGP-signed application is signed using a 1024-bit DSA key, and researchers have said that 1024-bit keys are inadequate and that DSA signatures are unsafe under the presence of certain other bugs! letās have the person send a paper letter for verification instead!ā. But convincingly forging a paper letter is probably considerably easier than mounting a cryptographic attack against the 1024-bit DSA key.
6 Likes
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.
@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.
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
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.
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