If/when will LE support .onion addresses?

I’m late to the party, but don’t any of you think this EV-only rules for .onion is coming as ignorance at best and malicious at worst?

Let see, If an entity want to run a “hidden” service with proper TLS certificate, this entity has to pass Extended Validation (EV) test.

So if Assange/Snowden want to run a TLS-secured Wikileaksabcxyz.onion in TOR they have to establish Wikileaks, Inc. and then pass the EV process.

What part of “hidden” isn’t clear enough to signify that the entity behind hidden service has no interest to reveal itself?

The rules is just stifling the encryption initiative if you ask me. Yes, there is technical ground for the rules as the one in Cloudflare blog post but as schoen and rugk has pointed, are those reasons good enough to strip majority of TOR user from getting a proper TLS encryption?.

I do hope LE will take a more active role in CA/Browser Forum on supporting DV cert for .onion…


Somewhere (maybe earlier in this post) an idea was brought forward that the onion hosts themselves would generate their own HTTPS keys based on the host address. Then there wouldn’t be a need for a CA since the client would only need to validate the key against the corresponding host address. Therefore, bypassing the need for a CA.

Of course it doesn’t solve the birthday problem I just mentioned, but would increase the adaption of HTTPS for onion addresses. Third party validation could be extra, though.

but that wouldnt make it much better than it is right now. because the Tor Key is already based on the host adress (well actually it’s the other way around with the address being the hash of the pubkey)

and if you can create the same key or a collision you could automatically get https.

I can’t see any practical difference, if you can create a collision you can perform a domain verification and then have a DV certificate


also TOR + EV can make sense for example to avoid a state level firewall or whatever

I agree. Although it would have HTTPS builtin as a result. It would enable the browsers to have DV certificates as a base. It doesn't solve the collision problem but does enhance the every-day security of the communications.

I dont really know what kinda keys tor uses for onions.
but as I said the main point is that tor already has end-to-end crypto for onions (unlike standard tor where the last endpoint could read anything) which is the reason why most onion names make no sense because they are (truncated) hashes of the onion key.

It could make sense if the user is outside of the Tor network and uses a special service (like proxy) to access .onion domains.

wait a sec something like that even exists? this defeats the whole purpose of tor.

Two times: Yes.

However such certs cannot be used for this as these Tor proxies of course have different addresses ( kdfjsakjfidsifsdfsd.onion-proxy.example for instance) and therefore the certs would not be recognized. That's because such proxies just use usual HTTPS certs.

I think he means proxy more in a browser-set proxy way where you set it in the browser.

then HTTPS cert checking certainly occurs (just like with any company proxy that doesnt sniff on HTTPS)

I am not aware of such proxies.

And of course this would also be an unlikely use scenario, so I doubt - even if it would be possible - that much onion server admins would support it.

well me neither but this is how proxies normally work

But Tor proxies are usually websites, which use Tor to access the site and deliver it over HTTP (hopefully, HTTPS) to the user.

okay lol. if it would be a normal proxy that just relays the Tor HTTP to the outside network, HTTPS COULD be useful but still, just get a portable tor client or whatever if you wanna use it, that’s safer

1 Like

(1) My understanding is that the Tor network rejects all but the first used onion address / public key association. So if you can find a collision, it does you no good, because requests will never be routed to your system as you did not create the first hash. The hash is just an index; it is not used cryptographically. I have not personally verified this, however.
(2) Hosting a file on an onion address proves that you own it, because it shows that you have the private key.
(3) So, if you can host a file on a .onion address, you deserve an SSL certificate for that address. The arguments against this sound rooted in ignorance of the behavior of the Tor network. A CA should not offer a certificate to an entity which can produce a hash collision only.
(4) Note, however, that SSL prevents against man-in-the-middle attacks, which it is almost the whole purpose of Tor to protect against already. If these attacks are reasonable to perform, the whole network is broken, and it is being used for some purpose other than its intended purpose.

Sorry to necro this thread, but there have been new developments in the field of Tor Hidden Services:
Tor will soon launch a new hidden service format that will have much stronger naming. Do you know if the next generation onion services will be eligible under CA/B rules for DV SSL, and if so will Let’s Encrypt support next generation onion domains?

Hi @BFeely,

I know we were waiting on the adoption of this change in order to remove concerns about cryptographic strength mismatch. Unfortunately, the eligibility of .onion names for DV certificates is not automatic even under these circumstances and still requires action by the CA/B Forum.

I’ll try to get an update on this for you.


the way i understand it is that:

  1. the .onion site address is a truncated version of a public key for the server
  2. it would therefore not be possible to bruteforce using only the .onion address
  3. during connection the client sends a unique secret encrypted with the hidden sites full public key that only the holder of the private key can decode.
  4. this means that if an attacker did brute-force a tor private key, it might only allow them to either take-over the site, or to impersonate it potentially. from my testing, the newest host is the one you connect to, so it would be more of a denial of service attack than anything useful for all that brute forcing.
  5. if Let’s Encrypt was to support it, it would need to sign a message every now and then, eg let’s encrypt would send a unique code challenge and the site owner would need to respond correct. then the CA could issue a cert maybe. mite need to be valid for ip address wildcard perhaps. or or or similar global ip space. ?

Certificates from Let’s Encrypt are always for DNS names so the IP addresses are not an issue. In the case of Tor instead of a name from the Internet’s DNS it’s a name from the .onion TLD which was reserved for this purpose.

CA/B usually moves quite slowly so this will be a matter for discussion over probably several months at least.