If/when will LE support .onion addresses?

candrews · August 22, 2018, 2:15am

What’s the latest news on this topic?

Tor has launched Hidden Services v3 which (as far as I can tell) has resolved the concerns about the onion addresses.

Is there a CA/B ballot in progress? Where can one learn more?

schoen · August 22, 2018, 7:01pm

I’m working on this but haven’t made much progress recently. I would suggest following the GitHub issue or this very forum thread. You can also subscribe to cabfpub (or the new server certificate working group list).

We have a draft ballot but it hasn’t been introduced or even circulated to the list yet.

_az · December 20, 2019, 6:02am

Looks like there’s some new movement towards allowing DV for v3 onion addresses and discussion about how it would work in ACME:

I wonder if it’s planned to make the server available as a hidden service. Either way, the requester IP is either going to be an exit node or a rendezvous point … which is going to make equitable rate limits a struggle.

cpu · December 20, 2019, 2:46pm

Definitely no plans to make the ACME API available as a hidden service.

tdelmas · February 20, 2020, 5:49pm

https://twitter.com/AlecMuffett/status/1230524385884360712

Alec Muffett
@AlecMuffett

Looks like the vote in favour of DV "Version 3 Onion" TLS certificates, passed!
https://cabforum.org/pipermail/servercert-wg/2020-February/001663.html

candrews · February 21, 2020, 2:09pm

Great news!

What is the next step?

orangepizza · February 22, 2020, 5:06am

make a acme-onion rfc draft so have a protocol extension for acme?
currently it has no defined way to implement callenge for onion address.

JonahAragon · March 10, 2020, 1:46pm

@schoen what does Ballot SC27v3 mean for Let’s Encrypt? Are you now free to issue certificates for v3 onions as soon as it’s implemented in ACME and/or Boulder, or are there other hurdles in the way of implementing this?

orangepizza · March 10, 2020, 2:57pm

while web endpoint have a way to attach payload at challenge list, it doesn’t really carried to VA and database doesn’t save it, so It will need to add column to current database,
and in boulder it doesn’t able to handle other then DNS name parameter.

schoen · March 10, 2020, 6:26pm

@JonahAragon, it has to pass its IP review period (during which CA/B Forum members can declare if they have patents that they believe would be infringed by implementing the procedures in the ballot). After that, Let’s Encrypt could issue these certificates at any time—though in practice both ACME and Boulder would need some work, and also the validation infrastructure because it would probably need to be able to access Tor as part of validations.

JonahAragon · March 10, 2020, 6:44pm

Sounds like I shouldn’t hold my breath then… Would the normal HTTP test work for domain validation, so all that needs to happen is Tor access on the validation infrastructure (and adding .onion as a valid TLD), or is it more complex than that?

schoen · March 10, 2020, 7:38pm

That could definitely work, although there is a more complex method available, and it’s possible that Let’s Encrypt or other CAs might prefer to adopt the more complex method instead.

orangepizza · March 10, 2020, 8:05pm

github.com/letsencrypt/boulder

Support for FQDNs under .onion

opened 07:02PM - 19 Dec 19 UTC

cpu

kind/feature status/blocked/spec area/va

## Background Historically the [CABF baseline requirements](https://cabforum.…org/wp-content/uploads/CA-Browser-Forum-BR-1.6.7.pdf) have considered FQDNs with `.onion` as the rightmost label "internal names" because the TLD is not registered in IANA's root zone database: > Internal Name: A string of characters (not an IP address) in a Common Name or Subject Alternative Name field of a Certificate that cannot be verified as globally unique within the public DNS at the time of certificate issuance because it does not end with a Top Level Domain registered in IANA’s Root Zone Database. To support HTTPS for `.onion` sites the ["Extended Validation Certificate Guidelines"](https://cabforum.org/wp-content/uploads/CA-Browser-Forum-EV-Guidelines-v1.7.1.pdf) specify a carve-out that allows issuing EV certificates for `.onion` FQDNs if extra steps specified in an Appendix are followed: > For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant’s control over the .onion Domain Name in accordance with Appendix F. The EV requirement and the additional `cabf-TorServiceDescriptor` certificate extension in Appendix F were largely intended to address weak cryptography used by tor v2 `.onion` addresses. Since the v3 address specification addresses those weaknesses there is now a [proposal in the CABF validation working group](https://cabforum.org/pipermail/validation/2019-December/001385.html) in the works by Wayne Thayer of Mozilla to change the CABF baseline requirements to allow DV issuance for `.onion` FQDNs that are implemented with the "v3" `.onion` address specification. ## Implementation notes If a ballot based on this proposal were to be approved Let's Encrypt/Boulder could in theory issue for `.onion` domains. This issue is to track some of the things we'd need to figure out to support that. It isn't a commitment to implement, but a collection of notes particularly focused on some challenges we would face. ### Domain control From an operational perspective adding a tor daemon adjacent to each of our VA instances to allow outbound `tor` communication to `.onion` sites to verify an agreed upon change to a website (via HTTP-01) is a substantial burden. It's a complex daemon in a memory unsafe language and we would need new monitoring and a lot of general SRE work to deploy it. We would probably prefer to implement proof of domain control support based on the "CSR validation" method described in Wayne's draft ballot since there would be no requirement to make an outbound connection to the `.onion` FQDN. Probably implementing the CSR validation properly would require the definition of a new ACME challenge type since there is a need to relay and verify additional information in the CSR (the `caSigningNonce` and the `applicantSigningNonce`). ### Rate limits Our rate limits are primarily based around the notion that folks can't create infinite eTLD+1's because of the cost associated with domain registration. In contrast `.onion` names can be minted infinitely without any substantial cost. We would need to think of a way to apply fair rate limits for `.onion` names in order to ensure fair distribution of our resources. We could have a global rate limit for `.onion` names but that invites DoSing the availability of these certificates for others by continually issuing until the global rate limit is reached. Making the rate limit per-account would shift the burden to the new registration per IP rate limit which today is quite generous. Similarly we could affect a rate limit by requester IP but this would also be generous (and IPv6 addresses are cheap/plentiful). ### Gauging demand It's difficult to gauge subscriber demand for `.onion` certificates because to date the requirement for EV certificates with a custom extension meant only ~1 commercial CA implemented support and the cost was likely prohibitive for most users. Without knowing the demand it's difficult to make a decision on how important allocating resources to the work required is.

Domain control

From an operational perspective adding a tor daemon adjacent to each of our VA instances to allow outbound tor communication to .onion sites to verify an agreed upon change to a website (via HTTP-01) is a substantial burden. It's a complex daemon in a memory unsafe language and we would need new monitoring and a lot of general SRE work to deploy it.

We would probably prefer to implement proof of domain control support based on the "CSR validation" method described in Wayne's draft ballot since there would be no requirement to make an outbound connection to the .onion FQDN. Probably implementing the CSR validation properly would require the definition of a new ACME challenge type since there is a need to relay and verify additional information in the CSR (the caSigningNonce and the applicantSigningNonce ).

RustyX · December 1, 2020, 10:41pm

Not sure that a Tor client must run adjacent to VA instances. With the distributed nature of the Tor network, topological locality isn't really a thing (in Tor, each packet is travelling 2-6 times around the globe already).

Why can't the Tor client be isolated? There are other services with high security demands (e.g. cloudflare's hidden resolver) that do connect to Tor already.

I don't see how a Tor service can maintain anonymity without the ACME server speaking Tor, as communicating with it via any other means would leak the requestor's IP address, which can (and often will) be related to the service's location.

orangepizza · December 2, 2020, 2:01am

I don't see how a Tor service can maintain anonymity without the ACME server speaking Tor

To ACME's rate limit have any meaning Clients can't keep anonymity, as both .onion name and acme account can printed like paper, because they are just crypto key. only real point account generation can be throttled is accounts generated per IP address.
as onion routing is by itself secure, I guess most thing LE needed for is linking surfacenet identity to onion page, by having both name in same certificate.

RustyX · December 2, 2020, 12:34pm

I guess there are two distinct needs for HTTPS .onion: DV with full anonymity, and OV/EV with no anonymity.

Many people I know are interested in the first option. The need to have a DV SSL for an .onion domain is purely technical - it is to establish secure context in the browser and to get rid of the broken lock icon. I see this as a shortcoming of the Tor browser itself, since Tor is already end-to-end encrypted on par with that of TLS (including PFS).

To address the issue of rate limiting, an Acme .onion service could charge a small fee, e.g. 1 XRP for each certificate issued (1 XRP is ~$0.65). I think XRP is a good fit because it's a non-PoW (i.e. "green") and a relatively stable coin with a low TX fee.

The validation of an .onion domain can indeed take place without communicating with the .onion service at all, as the CSR can be simply signed by the private key that corresponds to the .onion address.

orangepizza · January 3, 2021, 7:22am

I made a pebble request for this: but I'm not sure if I interperate draft right (like where the hack it get client nonce or jws payload structure of update-challenge (should I decode json twice?