I’ve spent some time working on ACME for Tor hidden services (you may have seen discussion of this work on the onion-advisors mailing list). Full details of the project are available at https://acmeforonions.org.
Attached is my proposal for a change to the Tor Rendezvous Specification to support the inclusion of CAA records in hidden service descriptors.
Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574. ICO register №: ZA782876. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively.
Did you mean "signed"? If it's just encrypted and MACed, then anyone who
can decrypt and check the MAC can also alter the contents, of course.
···
On Tue, Apr 25, 2023 at 01:02:28PM +0100, Q Misell via tor-dev wrote:
Security Considerations:
The second layer descriptor is encrypted and MACed in a way that only a party
with access to the secret key of the hidden service could manipulate what is
published there. Therefore, Tor CAA records have at least the same security as
those in the DNS secured by DNSSEC.
Yes, signed is what I meant. I will update the document.
Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574. ICO register №: ZA782876. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively.
Whilst I agree that in an ideal world CAs would be irrelevant, we do not live in an ideal world. My proposal is one of many ways that a certificate could be issued to hidden services.
Issuing standard TLS certificates to .onion domains allows HTTPS without modification to the browser. This allows non Tor Browsers user agents to access the Tor network via a proxy (SOCKS etc), doing otherwise would require all browsers to understand Tor. It also opens up new opportunities such as payment processing as current PCI DSS requirements do not allow non-standard TLS.
Current hidden services with HTTPS such as the BBC already use standard TLS certificates, however the process for these is extremely involved with current CAs. My IETF draft aims to make this a much simpler process via the already well-proven ACME.
Thanks,
Q
Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574. ICO register №: ZA782876. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively.
In order to prove the ownership of an onion address and create a certificate, the onion service operator generate public and private key as usual, and sign [certificate public key, certificate fields (like expiry date, Subject Common Name) and extensions (like key usage)] with their onion service private key, and place the signature and a copy of signed data as non-critical extension of a CSR known as onion certificate seed.
This onion certificate seed can be either self-signed or submitted to certificate authority to become a full certificate. It can be submitted to certificate authority over ACME for certificate issuance. The onion key signature and signed data is copied to the final certificate as non-critical extension after validation.
For Onion Native Application (like Tor Browser), a TLS certificate is trusted if it is issued by a trusted CA, or it has a valid onion certificate seed extension. This means this certificate issue model does not absolutely need any cooperative CA to work, so long as Tor Browser and other Tor Native application supported it by default, it would work as expected. For some application designed specifically for Tor, a onion service without a valid onion certificate seed extension may be rejected. For non-Onion-Native applications, a certificate issued by certificate authority will be necessary for it to pass validation.
It has the following advantages compare to the plan mentioned in your email:
Since the certificate public key and expiry date is covered by onion key’s signature, Certification Authority Authorization record is not necessary, as attacker could not generate a certificate under the attacker’s control, since attacker have no access to the public key. This also allow certificate authority to issue certificate without the need to have access to the Tor network or the onion service. (CA don’t wish to change the design of their airtight certificate issuing environment, don’t force them)
For Onion Native Application, this design works on day 1 without the need of any cooperative CA. Since currently a lot of onion service is access with Tor Browser, it will allow Tor Browser to push the adaption of this design with its weight. CA hates to break thing, this design gets things rolling to force trusted CAs to adapt it.
For Onion Native Application, this design allows valid certificate to be generated without contacting third party and publishing the onion service address. This would allow sensitive onion service to use TLS encryption without revealing its address to third party or public.
The onion certificate seed can be generated offline, which allow it to be stored in a secure/offline location.
It does not require any change to the C-Tor/Arti implementation, since it does not require either CA or even the hidden service request certificate itself connected to the Tor network.
Shelikhoo
···
On 25/4/2023 1:02 pm, Q Misell via tor-dev wrote:
Hi all,
I’ve spent some time working on ACME for Tor hidden services (you may have seen discussion of this work on the onion-advisors mailing list). Full details of the project are available at https://acmeforonions.org.
Attached is my proposal for a change to the Tor Rendezvous Specification to support the inclusion of CAA records in hidden service descriptors.
Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574. ICO register №: ZA782876. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively.
_______________________________________________
tor-dev mailing list
[tor-dev@lists.torproject.org](mailto:tor-dev@lists.torproject.org)
[https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev](https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev)
Your suggestion seems sound, and I’d like to see it progress further. However it is not in the CA/BF BR, so is unusable by CAs, and therefore out of scope of my project.
I suggest you take up your new method with the CA/BF for addition to their BR.
Thanks,
Q
···
On 25/4/2023 1:02 pm, Q Misell via tor-dev wrote:
Hi all,
I’ve spent some time working on ACME for Tor hidden services (you may have seen discussion of this work on the onion-advisors mailing list). Full details of the project are available at https://acmeforonions.org.
Attached is my proposal for a change to the Tor Rendezvous Specification to support the inclusion of CAA records in hidden service descriptors.
Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574. ICO register №: ZA782876. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively.
_______________________________________________
tor-dev mailing list
[tor-dev@lists.torproject.org](mailto:tor-dev@lists.torproject.org)
[https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev](https://e.as207960.net/w4bdyj/LfTlGLyS)
In this version I added that the onion certificate seed can also include nonce from CA and ACME client, so that it would have the same proof online key possession propriety of the current version of baseline requirement.
Shelikhoo
···
On 5/5/2023 8:39 pm, Q via tor-dev wrote:
Hi Shelikhoo,
Your suggestion seems sound, and I’d like to see it progress further. However it is not in the CA/BF BR, so is unusable by CAs, and therefore out of scope of my project.
I suggest you take up your new method with the CA/BF for addition to their BR.
In order to prove the ownership of an onion address and create a certificate, the onion service operator generate public and private key as usual, and sign [certificate public key, certificate fields (like expiry date, Subject Common Name) and extensions (like key usage)] with their onion service private key, and place the signature and a copy of signed data as non-critical extension of a CSR known as onion certificate seed.
This onion certificate seed can be either self-signed or submitted to certificate authority to become a full certificate. It can be submitted to certificate authority over ACME for certificate issuance. The onion key signature and signed data is copied to the final certificate as non-critical extension after validation.
For Onion Native Application (like Tor Browser), a TLS certificate is trusted if it is issued by a trusted CA, or it has a valid onion certificate seed extension. This means this certificate issue model does not absolutely need any cooperative CA to work, so long as Tor Browser and other Tor Native application supported it by default, it would work as expected. For some application designed specifically for Tor, a onion service without a valid onion certificate seed extension may be rejected. For non-Onion-Native applications, a certificate issued by certificate authority will be necessary for it to pass validation.
It has the following advantages compare to the plan mentioned in your email:
Since the certificate public key and expiry date is covered by onion key’s signature, Certification Authority Authorization record is not necessary, as attacker could not generate a certificate under the attacker’s control, since attacker have no access to the public key. This also allow certificate authority to issue certificate without the need to have access to the Tor network or the onion service. (CA don’t wish to change the design of their airtight certificate issuing environment, don’t force them)
For Onion Native Application, this design works on day 1 without the need of any cooperative CA. Since currently a lot of onion service is access with Tor Browser, it will allow Tor Browser to push the adaption of this design with its weight. CA hates to break thing, this design gets things rolling to force trusted CAs to adapt it.
For Onion Native Application, this design allows valid certificate to be generated without contacting third party and publishing the onion service address. This would allow sensitive onion service to use TLS encryption without revealing its address to third party or public.
The onion certificate seed can be generated offline, which allow it to be stored in a secure/offline location.
It does not require any change to the C-Tor/Arti implementation, since it does not require either CA or even the hidden service request certificate itself connected to the Tor network.
Shelikhoo
_______________________________________________
tor-dev mailing list
[tor-dev@lists.torproject.org](mailto:tor-dev@lists.torproject.org)
[https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev](https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev)
On 25/4/2023 1:02 pm, Q Misell via tor-dev wrote:
Hi all,
I’ve spent some time working on ACME for Tor hidden services (you may have seen discussion of this work on the onion-advisors mailing list). Full details of the project are available at https://acmeforonions.org.
Attached is my proposal for a change to the Tor Rendezvous Specification to support the inclusion of CAA records in hidden service descriptors.
Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574. ICO register №: ZA782876. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively.
_______________________________________________
tor-dev mailing list
[tor-dev@lists.torproject.org](mailto:tor-dev@lists.torproject.org)
[https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev](https://e.as207960.net/w4bdyj/LfTlGLyS)
I've merged this as proposal 343! I like it, this seems very simple approach
especially for the ACME support that would allow us to roll in within the
existing CA infrastructure. As you noted previously not perfect but this is
what the world has right now.
I took a look at your C-tor patch and I would strongly encourage you to submit
a MR to our Gitlab.
Thanks!
David
···
On 25 Apr (13:02:28), Q Misell via tor-dev wrote:
Hi all,
I've spent some time working on ACME for Tor hidden services (you may have
seen discussion of this work on the onion-advisors mailing list). Full
details of the project are available at ACME for .onion domains
Attached is my proposal for a change to the Tor Rendezvous Specification to
support the inclusion of CAA records in hidden service descriptors.
My fork of Tor implementing publishing these records is available at GitHub - AS207960/tor
