onion address support

[chgans]

Hi there,

This is more a server side than a client side issue, but it would be really nice if "let's encrypt" supports TOR's onion services.

[schoen]

Hi,

As someone who cares about this issue quite a lot, I would say that this is 100% a server-side issue (in terms of the prerequisites for having it even potentially happen). Indeed, it's a policy issue with further prerequisites outside of the Let's Encrypt CA: the places it needs to be addressed are in the CA/Browser Forum, and likely, IETF.

[chgans]

OK, I'll post a message on the IETF mailing list.
If you're subscribed to it, don't hesitate to show up once i've posted the message.

[schoen]

Huh, which IETF list did you think is appropriate? I've been trying to figure this out.

The last formal proposal to make .onion and other analogous names have an official status

https://tools.ietf.org/html/draft-grothoff-iesg-special-use-p2p-names-02

isn't associated with any particular IETF working group.

[schoen]

Some other resources on this discussion:

https://blog.digicert.com/anonymous-facebook-via-tor/
https://cabforum.org/pipermail/public/2014-October/thread.html#4210
https://cabforum.org/pipermail/public/2014-November/thread.html#4569

[chgans]

Hi! Thanks for the link. Actually you've been faster than me for the other links!

I was thinking about the ACME ML hosted at IETF https://www.ietf.org/mailman/listinfo/acme. it is mention here https://letsencrypt.org/getinvolved/

Related as well:
https://blog.torproject.org/blog/facebook-hidden-services-and-https-certs

[schoen]

I see. I think there are two issues -- how to make .onion official enough that there's more widespread comfort with issuing certs for it, and how a CA should verify a .onion address.

Theoretically these things could happen independently, though they might be interrelated. The first one unfortunately doesn't seem to have anything to do with ACME at all, while the second one could potentially be topical for the ACME mailing list although some people might be confused by it. In our current ACME nomenclature it could be seen as proposing new challenge types (if you think they would be more suitable than doing the existing DVSNI or something). Some of the folks in the CA/B thread did seem to think it would be a good idea to make more direct use of the hidden service's private key rather than just doing CA-to-hidden-service probing inside the Tor network.

Maybe the second issue should actually be split out even further, into "what kind of verification should a CA do before issuing a cert to an onion service?" and "given an understanding of that issue, how would the ACME protocol support this kind of verification?". That still leaves the first issue of "can the Internet community come to see and recognize Tor hidden services as an appropriate official public meaning for the name .onion?" (which I do think should be discussed further at IETF, but probably not on the ACME mailing list).

[chgans]

That's quite a good summary.
I am personally after anonymous SSL certificates for anonymous service over anonymous network! ;)

[lilyanatia]

@chgans for that you could use a self-signed certificate, or https://qm3monarchzifkwa.onion/ca/.

[ricardobrg]

@hotaru2k3 but it's considered untrusted by the browser (even tor browser). As @schoen said the main issue here - for me - is a CA that verifies a .onion address.
I've just installed letsencrypt and I'm running some tests in my hidden services. I'll update here the results ASAP...

[MadMarx]

Looks like this has been greenlighted in the higher spheres and is now only a matter of implementation: https://blog.digicert.com/onion-officially-recognized-special-use-domain/

[schoen]

MadMarx writes:

Looks like this has been greenlighted in the higher spheres and is now only a matter of implementation: https://blog.digicert.com/onion-officially-recognized-special-use-domain/

The CA/Browser Forum rule in response to this, as it stands, would only allow issuance of EV certificates to onion names (which is what Digicert does). We will perhaps have to join the CA/B Forum and make a motion there to extend the permissibility of issuance for DV certificates (which is what we issue). Alternately, I've seen a discussion about having the Tor Browser recognize some kind of special-case certificates that are only for its consumption, not for other browsers, and having Let's Encrypt or some other entity issue Tor Browser-friendly DV certificates (that other browsers won't consume) for onion names.

[cyphar]

Alternately, I've seen a discussion about having the Tor Browser recognize some kind of special-case certificates that are only for its consumption, not for other browsers, and having Let's Encrypt or some other entity issue Tor Browser-friendly DV certificates (that other browsers won't consume) for onion names.

A much better system is to have a single DV cert where one of the AltNames is the onion address. This results in actually providing one of the main features of TLS: authenticity verification. Thus, if you're BigCo, you can have your onion address share the same certificate -- thus verifying to all users that bigco.com and bigcoXXXX.onion are run by the same people. Tor already provides end-to-end encryption for onion addresses, authenticity is what's missing.

[cowlicks]

For anyone who is wondering: EV certs are "extended validation certificates", the issuing CA goes through extra steps verifying the identity of the requesting entity. Letsencrypt cannot do this. LE issues DV (domain validation) certs, meaning it has just validated that the requesting entity owns the domain for which the cert will be issued. Only EV certs are approved for .onion sites, we need DV certs to be approved for certbot to have .onion support.

There was some discussion about this on the CA/Browser forum mailing list. The thread is broken up, I'll try to summarize:

Alec Muffett asks how to get a Onion-capable SSL cert for his blog. He can't get an EV cert as an individual. Explains why he needs this. (link)

Ryan Sleevi responds explaining the decision to limit issuance to EV certificates:

• There are questions about the cryptographic strength of the .onion naming scheme. It uses RSA-1024 and SHA-1, both of which should be considered deprecated.
• A cyrptographic attack on the .onion naming scheme would compromise DV certificates, but not EV.
• CAs believe it is their responsibility to police content by revoking certificates in the name of "protecting the users". Allowing unattributed certificates is contrary to this (?).
  (link)

Paul Syverson responds to Ryan's explanation:

• The naming scheme is transitioning to SHA-256 and ed25519.
• Even without that, demonstrating ownership of a .onion "stronger" than demonstrating ownership of a registered domain over http.
• CAs can revoke the certificate of an onionsite just as they could for a registered domain.
  (link)

Ryan Sleevi responds to Paul. He explains how with the Tor service descriptor extension and certificate transparency, a cryptographic attack on the onion naming scheme based on factoring RSA-1024 or a SHA-1 collision could be mitigated with EV certificates but not DV. But the introduction of DV certificates could allow for downgrade to DV attacks. And how catastrophic one of these attacks would be. The oninonsite could never again be trusted, ever. Ryan does not agree with CAs belief they should police content, but they must be dealt with amicably in the CA/Browser forum.
(link).

(end thread)

Has there been any more recent work lobbying the CA/Browser forum?

What is the state of updating the tor network? If I understand correctly, onionsites created with RSA-1024 will always be vulnerable because the name is based on the key. And you would have to create a whole new key, and therefore name, if you wanted to use ed25519.

[evilaliv3]

@pde is there by the chance any update on this topic?

[diveyez]

BUMP

[schoen]

Hi folks,

As an update, EFF has joined the CA/Browser Forum as an Interested Party so that I can discuss the topic there. I have posted about the issue on the cabfpub mailing list and not received strong opposition there.

I have been drafting a CA/B Forum ballot together with a colleague from another CA and we are currently looking for some browser feedback before introducing the ballot there. I'm hopeful that a draft ballot will be presented for discussion around the beginning of March and hopefully submitted for voting in April. If the ballot passes, there will still need to be a decision on whether to implement it by each CA.

As our draft is currently written, we wouldn't need changes to the ACME protocol to support at least some validation methods, but there would definitely need to be changes on both the client and server sides to understand how to do validation on onion sites.

Per previous discussions at the Forum which I wasn't a part of, we are only proposing DV support for next-generation onion services (https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt). A few years ago, there was significant opposition to DV certificates for first-generation onion services, for reasons that I don't find compelling, but that people have encouraged me not to try to reopen.

If you need a certificate for an onion service and your service is operated by an entity that is not anonymous, you can currently pay for an EV certificate from DigiCert (including for first-generation onion names).

https://crt.sh/?Identity=%25.onion

I know it's frustrating that these things are taking years rather than weeks, but people are very cautious about these issuance rules.

Since this isn't Certbot-specific and since it's super-premature for Certbot itself to implement anything related to this, I would suggest continuing discussions over at the Community Forum, where Let's Encrypt issuance policy is totally on-topic (and there's even a category for issuance policy discussions and several existing onion cert-related threads).

https://community.letsencrypt.org/

Thanks!

[ohemorange]

Closing in favor of discussion elsewhere.