@BFeely, probably not yet, because of industry rules that currently limit .onion certificates to EV, which Let’s Encrypt doesn’t issue at all.
Really there are such
<your bad word here> industry rules?
There are many reasons why having proper TLS/SSL certs setup for hidden services should be a priority. We run an non-profit private Tor-only e-mail service. It requires our members to connect to mail services (POP3/IMAP/SMTP) using TLS. Without valid .onion domain certs, our clients continue to get security warnings since even if we used lelantos.org certs… there would still be a mismatch when they connect to our hidden services.
This is but one example why certs are so important for .onion domains. Private key signing is quite robust and simple to implement.
I would appreciate any attention and energy you can commit to making this minor change to your software.
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
Please see the just-posted item at
for more about this issue.
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!
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.
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.
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.
@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.
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
tlsni-01 or a dns poisoning on
dns-01 for the ACME server. Just rent a amazon EC2 for CPU power.