Letsencrypt for .onion?

Issuance Policy
23

I need a (stupid) ssl certificate for an hidden service to be able to send push notifications (https://developer.mozilla.org/en-US/docs/Web/API/notification). as simple as that. It is technically easy to do, although unsupported.

24

why doesnā€™t tor browser itself insert itā€™s own CA (name constrained locked to .onion domains) and automatically write certificate to onion domain with matching public key?

2 Likes
25

That would involve putting the certificate authorityā€™s private key in the browser. If I was an attacker Iā€™d just download the browser source code, extract the private key and sign certs for whatever .onion domains Iā€™d like.

2 Likes
26

At that point, we could ask why browsers don't just treat onion (v3) services as secure contexts? Or even just the "Tor Browser" alone could do so, if it is the de facto browser for the product.

It's not clear to me why, if onion services make the same confidentiality/authenticity/integrity promises as TLS, layering TLS over it is considered productive or beneficial:

From the Tor website:

All traffic between Tor users and onion services is end-to-end encrypted, so you do not need to worry about connecting over HTTPS.

Just defence-in-depth?

3 Likes
27

Because this is a common perspective, I want to make it very clear why supporting https for .onion domains is important: it makes sense to add an https cert for Onion Services when adding a .onion domain as an alias to an existing, complex site that has http -> https redirects buried everywhere

Personally, I'm trying to add a .onion as a secondary domain for all my existing wordpress sites. Years ago, I migrated from http to https when Let's Encrypt first came out. When I made that transition, I checked all the boxes to "redirect http to https" everywhere I could: in my web server's config, in the caching reverse proxies, in the CMS core config, in various plugins, themes, etc. Now that I'm trying to add a .onion to my existing websites, I'm finding that some of my sites work OK, but others stubbornly refuse to serve traffic over http. They just 301 redirect to https://xyz.onion (which of course doesn't work). Isolating and changing this behavior is non-trivial, especially for large sites.

There's huge privacy benefits to be gained by site admins making their existing websites accessible to tor users through onion services, but--since all our great efforts to migrate from http to https in the past years--it's not always trivial to just point a .onion at a website and have all the infrastructure we hardened just accept serving over http again.

If ACME could support issuing certs for .onion sites, this would lower the barrier of entry for sysadmins to be able to bring their existing websites onto the tor network, which would be another huge benefit for the privacy of Internet users everywhere.

See also:

3 Likes
28

I definitely agree, currently running into this issue currently trying to make my Mastodon instance available to the Tor network...

2 Likes
29

Any word on when certs for .onion will become available via certbot?
Isn't is just a matter of giving the registration server access to make HTTP requests over Tor?

For reference:

1 Like
30

The reason for this is that the browser and the actual TOR client is different softwares. Technically, the browser connects to a SOCKS5 proxy on 127.0.0.1 and then asks it to resolve a .onion domain. If a browser would to treat *.onion as a secure context as itself, a rogue party could hijack the connection of a NON-TOR user, and then ask the browser to redirect to a *.onion URL, which then is, by the attacker, resolved to his server, and he would then gain access to all "secure" tools over a unencrypted connection.

In some cases, the web browser and TOR client won't even run on the same physical hardware, since some users use a "central TOR router" (looks like a normal home router but with custom firmware to handle TOR) to handle their TOR traffic from their whole home network without having to maintain a circuit for every client in their home network.

One thing the TOR software could do, is to add its own .onion CA into the system - and actually GENERATE a keypair (so every .onion system would have different CA private keys) and then mint certificates on-the-fly. For those using TOR in central routers, the name-constrained certificate could be on a downloadable CA link, which was generated during setup of the central TOR server inside home NAT router.

31

If Let's Encrypt really going to support .onion I have 3 suggestions.

  1. Allow torsocks certbot ... or reroute to Tor SOCKS proxy because the onion servers are probably blocking outgoing traffic except Tor traffic. Last time I run it over torsocks your server rejected Tor request!!!!!
  2. Stop using Cloud flare proxy as LE server. Related to above the Cloud flare is known to block Tor.

That being said I believe the Tor Browser SHOULD ignore the warning and show HTTPSified Onion websites.
Displaying yellow insecure errorscreen, it just does not make sense at all as the Tor traffic is already verified...

If any of you agrees be sure to send your message from https://anonticket.onionize.space/

34

This isnā€™t a priority for Letā€™s Encrypt right now. If and when we support .onion, of course we should consider making our API available over tor itself.

5 Likes