Re: Using hidden service key with TLS client authentication
Hi techmetx11, (Attempted resend since send from my Navy mail appearently failed to reach tor-dev. Apologies if you got this twice. -PFS) I don't know if this fits what you need. But we have used the onion address as subdomain to put it into TLS certificates in the case where there is an associated domain name. E.g. Mullvad has a TLS certificate with the following SANs o54hon2e2vj6c7m3aqqu6uyece65by3vgoxxhlqlsvkmacw6a7m7kiadonion.mullvad.net o54hon2e2vj6c7m3aqqu6uyece65by3vgoxxhlqlsvkmacw6a7m7kiadonion.www.mullvad.net/ We've used this in a couple of ways, for self-authenticating traditional addresses and for sauteed onions. See e.g. https://arxiv.org/abs/2110.03168 and https://www.sauteed-onions.org/ Happy to talk more if asked about recent work on associating onion addresses with atproto handles as alternative/additional meaningful address. In case it helps for your use case, note that you don't need to keep the service accessible at the registered domain address. It only has to be available during issuance (depending on the means of verification used). You can also just get a certificate for an onion address. Issuance via ACME is still not available last I checked despite the efforts of Q Misell and others. Last I checked (some time ago) you can get a DV cert issued manually from HARICA or an EV cert from DigiCert. The syverSAN technique OTOH works fine with Let's Encrypt issuance. Hope that helps. Si sanus es, sanus sum, Paul
On 6/8/26, 4:32 AM, "techmetx11 via tor-dev" wrote:
Hi tor-dev mailing list,
Is there a way to capsulate a Tor hidden service Ed25519 private key inside a TLS EE certificate and use it in TLS?
I wanted to use this specifically for XMPP's server-to-server TLS connections, which uses mTLS to prove if the client connecting is who they say they are. Currently with XMPP Tor server-to-server connections, we have to use dialback (telling the server to connect back to the client to authenticate its identity, https://xmpp.org/extensions/xep-0220.html <https://xmpp.org/extensions/xep-0220.html>) to prove it, which is a legacy and insecure form of server-to-server authentication
If this is possible, then it would get rid of a reason to keep dialback around and less roundtrip for the server authentication.
Kind regards,
techmetx11
_______________________________________________ tor-dev mailing list -- tor-dev@lists.torproject.org <mailto:tor-dev@lists.torproject.org> To unsubscribe send an email to tor-dev-leave@lists.torproject.org <mailto:tor-dev-leave@lists.torproject.org>
I feel like this would work if your service had a clear-web counterpart, but not much if you're just a onion-only service. I was looking for something that is able to authenticate a onion service, regardless of what the service has (which doesn't have to be TLS auth if it can't, but ideally it should). Given that the servers already have a custom certificate validation function (due to CAs like Let's Encrypt making it pretty difficult to have a signed certificate for client authentication), I was thinking I could put a onion service's key in a X.509 certificate, and check if the public key parsed from the onion service domain matches the public key in the certificate within the validation function. I haven't managed to get that working though, unfortunately On 6/11/26 1:21 PM, Paul Syverson wrote:
Hi techmetx11,
(Attempted resend since send from my Navy mail appearently failed to reach tor-dev. Apologies if you got this twice. -PFS)
I don't know if this fits what you need. But we have used the onion address as subdomain to put it into TLS certificates in the case where there is an associated domain name. E.g. Mullvad has a TLS certificate with the following SANs
o54hon2e2vj6c7m3aqqu6uyece65by3vgoxxhlqlsvkmacw6a7m7kiadonion.mullvad.net o54hon2e2vj6c7m3aqqu6uyece65by3vgoxxhlqlsvkmacw6a7m7kiadonion.www.mullvad.net/
We've used this in a couple of ways, for self-authenticating traditional addresses and for sauteed onions.
See e.g. https://arxiv.org/abs/2110.03168 and https://www.sauteed-onions.org/ Happy to talk more if asked about recent work on associating onion addresses with atproto handles as alternative/additional meaningful address.
In case it helps for your use case, note that you don't need to keep the service accessible at the registered domain address. It only has to be available during issuance (depending on the means of verification used).
You can also just get a certificate for an onion address. Issuance via ACME is still not available last I checked despite the efforts of Q Misell and others. Last I checked (some time ago) you can get a DV cert issued manually from HARICA or an EV cert from DigiCert.
The syverSAN technique OTOH works fine with Let's Encrypt issuance. Hope that helps.
Si sanus es, sanus sum, Paul
On 6/8/26, 4:32 AM, "techmetx11 via tor-dev" wrote:
Hi tor-dev mailing list,
Is there a way to capsulate a Tor hidden service Ed25519 private key inside a TLS EE certificate and use it in TLS?
I wanted to use this specifically for XMPP's server-to-server TLS connections, which uses mTLS to prove if the client connecting is who they say they are. Currently with XMPP Tor server-to-server connections, we have to use dialback (telling the server to connect back to the client to authenticate its identity, https://xmpp.org/extensions/xep-0220.html <https://xmpp.org/extensions/xep-0220.html>) to prove it, which is a legacy and insecure form of server-to-server authentication
If this is possible, then it would get rid of a reason to keep dialback around and less roundtrip for the server authentication.
Kind regards,
techmetx11
_______________________________________________ tor-dev mailing list -- tor-dev@lists.torproject.org <mailto:tor-dev@lists.torproject.org> To unsubscribe send an email to tor-dev-leave@lists.torproject.org <mailto:tor-dev-leave@lists.torproject.org>
Hi techmetx11, Sorry if I was too brief (rarely a problem for me). If you don't have access to a registered domain at all, even temporarily, then my proposal will not work. But if you do, I believe you can use it to pass the authentication checks for issuance from Let's Encrypt and then drop having it be reachable or capable of updating DNS records. First, making an assumption of yours explicit: Onion services are self-authenticating. That's a virtue. So what I'm guessing you want is some accepted authority signing a credential offering identity/consistency/transparency/? I could say a _lot_ about contextual trust and recognizing different authorities, but I'll stop myself and just assume for now that CAs, in particular Let's Encrypt, are sufficient authorities for your needs. Easiest scenario one: You have some domain you can use, example.com, and you're OK getting certs to go with all the onion addresses you have. (Not sure of the limit, it was apparently at least 7 at one time. Cf. https://community.letsencrypt.org/t/subdomain-certificates/138733 ) Now get a TLS certificate from LE for example.com that includes the SANs [onion1].example.com, [onion2].example.com, etc. You will need to be able to pass DNS or nonce checks or... that LE checks for example.com during issuance. Once you have these, you no longer have maintain reachability at example.com Will not discuss in this message how to use those certificates for (alleged) brevity. Another scenario: You have a bunch of registered domain names at your disposal, example1.com, example2,com,..., examplen.com You want credentials for onion addresses [onion1], onionm] where m \leq n Now get a TLS certificate from LE for [onion1].example1.com another for [onion2].example2.com, etc. You will need to be able to pass DNS or nonce checks or... LE checks for each [onioni].examplei.com during issuance. Once you have these, you no longer have maintain reachability at the various examplei.com Will not discuss in this message how to use those certificates for (alleged) brevity. Another scenario: you just have one registered domain at your disposal, as in the first scenario, but you want to get (separate) certificates to multiple onion addresses Follow same procedures as above scenarios, but for [onion1].sub1.example.com, [onion2],sub2.example.com, etc. I don't know if any of these will work for you, The possible show-stopping assumption is if you don't have any registered domain at which you can offer connectivity even briefly just for certificate issuance. Hope this is a little clearer anyway. SSS, Paul On Tue, Jun 16, 2026 at 12:10:56PM +0100, techmetx11 wrote:
I feel like this would work if your service had a clear-web counterpart, but not much if you're just a onion-only service.
I was looking for something that is able to authenticate a onion service, regardless of what the service has (which doesn't have to be TLS auth if it can't, but ideally it should).
Given that the servers already have a custom certificate validation function (due to CAs like Let's Encrypt making it pretty difficult to have a signed certificate for client authentication), I was thinking I could put a onion service's key in a X.509 certificate, and check if the public key parsed from the onion service domain matches the public key in the certificate within the validation function.
I haven't managed to get that working though, unfortunately
On 6/11/26 1:21 PM, Paul Syverson wrote:
Hi techmetx11,
(Attempted resend since send from my Navy mail appearently failed to reach tor-dev. Apologies if you got this twice. -PFS)
I don't know if this fits what you need. But we have used the onion address as subdomain to put it into TLS certificates in the case where there is an associated domain name. E.g. Mullvad has a TLS certificate with the following SANs
o54hon2e2vj6c7m3aqqu6uyece65by3vgoxxhlqlsvkmacw6a7m7kiadonion.mullvad.net o54hon2e2vj6c7m3aqqu6uyece65by3vgoxxhlqlsvkmacw6a7m7kiadonion.www.mullvad.net/
We've used this in a couple of ways, for self-authenticating traditional addresses and for sauteed onions.
See e.g. https://arxiv.org/abs/2110.03168 and https://www.sauteed-onions.org/ Happy to talk more if asked about recent work on associating onion addresses with atproto handles as alternative/additional meaningful address.
In case it helps for your use case, note that you don't need to keep the service accessible at the registered domain address. It only has to be available during issuance (depending on the means of verification used).
You can also just get a certificate for an onion address. Issuance via ACME is still not available last I checked despite the efforts of Q Misell and others. Last I checked (some time ago) you can get a DV cert issued manually from HARICA or an EV cert from DigiCert.
The syverSAN technique OTOH works fine with Let's Encrypt issuance. Hope that helps.
Si sanus es, sanus sum, Paul
On 6/8/26, 4:32 AM, "techmetx11 via tor-dev" wrote:
Hi tor-dev mailing list,
Is there a way to capsulate a Tor hidden service Ed25519 private key inside a TLS EE certificate and use it in TLS?
I wanted to use this specifically for XMPP's server-to-server TLS connections, which uses mTLS to prove if the client connecting is who they say they are. Currently with XMPP Tor server-to-server connections, we have to use dialback (telling the server to connect back to the client to authenticate its identity, https://xmpp.org/extensions/xep-0220.html <https://xmpp.org/extensions/xep-0220.html>) to prove it, which is a legacy and insecure form of server-to-server authentication
If this is possible, then it would get rid of a reason to keep dialback around and less roundtrip for the server authentication.
Kind regards,
techmetx11
_______________________________________________ tor-dev mailing list -- tor-dev@lists.torproject.org <mailto:tor-dev@lists.torproject.org> To unsubscribe send an email to tor-dev-leave@lists.torproject.org <mailto:tor-dev-leave@lists.torproject.org>
On 6/16/26 5:20 PM, Paul Syverson via tor-dev wrote:
Hi techmetx11,
Sorry if I was too brief (rarely a problem for me).
If you don't have access to a registered domain at all, even temporarily, then my proposal will not work.
But if you do, I believe you can use it to pass the authentication checks for issuance from Let's Encrypt and then drop having it be reachable or capable of updating DNS records.
First, making an assumption of yours explicit: Onion services are self-authenticating. That's a virtue. So what I'm guessing you want is some accepted authority signing a credential offering identity/consistency/transparency/?
Not really. Let's assume I have an endpoint meant for servers that wants to identify anybody who connects to it. I want a way to validate a incoming connection from a .onion server is from that actual .onion domain, assuming we have complete control over the server's TLS certificate verification function. This means you don't have to regard any sort of authority, if you don't want to. How would you handle this?
I could say a _lot_ about contextual trust and recognizing different authorities, but I'll stop myself and just assume for now that CAs, in particular Let's Encrypt, are sufficient authorities for your needs.
Easiest scenario one: You have some domain you can use, example.com, and you're OK getting certs to go with all the onion addresses you have. (Not sure of the limit, it was apparently at least 7 at one time. Cf. https://community.letsencrypt.org/t/subdomain-certificates/138733 )
Now get a TLS certificate from LE for example.com that includes the SANs [onion1].example.com, [onion2].example.com, etc.
You will need to be able to pass DNS or nonce checks or... that LE checks for example.com during issuance.
Once you have these, you no longer have maintain reachability at example.com
Will not discuss in this message how to use those certificates for (alleged) brevity.
Another scenario: You have a bunch of registered domain names at your disposal, example1.com, example2,com,..., examplen.com
You want credentials for onion addresses [onion1], onionm] where m \leq n
Now get a TLS certificate from LE for [onion1].example1.com another for [onion2].example2.com, etc.
You will need to be able to pass DNS or nonce checks or... LE checks for each [onioni].examplei.com during issuance.
Once you have these, you no longer have maintain reachability at the various examplei.com
Will not discuss in this message how to use those certificates for (alleged) brevity.
Another scenario: you just have one registered domain at your disposal, as in the first scenario, but you want to get (separate) certificates to multiple onion addresses
Follow same procedures as above scenarios, but for [onion1].sub1.example.com, [onion2],sub2.example.com, etc.
I don't know if any of these will work for you, The possible show-stopping assumption is if you don't have any registered domain at which you can offer connectivity even briefly just for certificate issuance. Hope this is a little clearer anyway.
SSS, Paul
On Tue, Jun 16, 2026 at 12:10:56PM +0100, techmetx11 wrote:
I feel like this would work if your service had a clear-web counterpart, but not much if you're just a onion-only service.
I was looking for something that is able to authenticate a onion service, regardless of what the service has (which doesn't have to be TLS auth if it can't, but ideally it should).
Given that the servers already have a custom certificate validation function (due to CAs like Let's Encrypt making it pretty difficult to have a signed certificate for client authentication), I was thinking I could put a onion service's key in a X.509 certificate, and check if the public key parsed from the onion service domain matches the public key in the certificate within the validation function.
I haven't managed to get that working though, unfortunately
On 6/11/26 1:21 PM, Paul Syverson wrote:
Hi techmetx11,
(Attempted resend since send from my Navy mail appearently failed to reach tor-dev. Apologies if you got this twice. -PFS)
I don't know if this fits what you need. But we have used the onion address as subdomain to put it into TLS certificates in the case where there is an associated domain name. E.g. Mullvad has a TLS certificate with the following SANs
o54hon2e2vj6c7m3aqqu6uyece65by3vgoxxhlqlsvkmacw6a7m7kiadonion.mullvad.net o54hon2e2vj6c7m3aqqu6uyece65by3vgoxxhlqlsvkmacw6a7m7kiadonion.www.mullvad.net/
We've used this in a couple of ways, for self-authenticating traditional addresses and for sauteed onions.
See e.g. https://arxiv.org/abs/2110.03168 and https://www.sauteed-onions.org/ Happy to talk more if asked about recent work on associating onion addresses with atproto handles as alternative/additional meaningful address.
In case it helps for your use case, note that you don't need to keep the service accessible at the registered domain address. It only has to be available during issuance (depending on the means of verification used).
You can also just get a certificate for an onion address. Issuance via ACME is still not available last I checked despite the efforts of Q Misell and others. Last I checked (some time ago) you can get a DV cert issued manually from HARICA or an EV cert from DigiCert.
The syverSAN technique OTOH works fine with Let's Encrypt issuance. Hope that helps.
Si sanus es, sanus sum, Paul
On 6/8/26, 4:32 AM, "techmetx11 via tor-dev" wrote:
Hi tor-dev mailing list,
Is there a way to capsulate a Tor hidden service Ed25519 private key inside a TLS EE certificate and use it in TLS?
I wanted to use this specifically for XMPP's server-to-server TLS connections, which uses mTLS to prove if the client connecting is who they say they are. Currently with XMPP Tor server-to-server connections, we have to use dialback (telling the server to connect back to the client to authenticate its identity, https://xmpp.org/extensions/xep-0220.html <https://xmpp.org/extensions/xep-0220.html>) to prove it, which is a legacy and insecure form of server-to-server authentication
If this is possible, then it would get rid of a reason to keep dialback around and less roundtrip for the server authentication.
Kind regards,
techmetx11
_______________________________________________ tor-dev mailing list -- tor-dev@lists.torproject.org <mailto:tor-dev@lists.torproject.org> To unsubscribe send an email to tor-dev-leave@lists.torproject.org <mailto:tor-dev-leave@lists.torproject.org>
tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-leave@lists.torproject.org
On Tue, Jun 16, 2026 at 05:34:48PM +0100, techmetx11 via tor-dev wrote:
On 6/16/26 5:20 PM, Paul Syverson via tor-dev wrote:
Hi techmetx11,
Sorry if I was too brief (rarely a problem for me).
If you don't have access to a registered domain at all, even temporarily, then my proposal will not work.
But if you do, I believe you can use it to pass the authentication checks for issuance from Let's Encrypt and then drop having it be reachable or capable of updating DNS records.
First, making an assumption of yours explicit: Onion services are self-authenticating. That's a virtue. So what I'm guessing you want is some accepted authority signing a credential offering identity/consistency/transparency/?
Not really.
Let's assume I have an endpoint meant for servers that wants to identify anybody who connects to it. I want a way to validate a incoming connection from a .onion server is from that actual .onion domain, assuming we have complete control over the server's TLS certificate verification function. This means you don't have to regard any sort of authority, if you don't want to.
How would you handle this?
Oh. That might be much easier. You might be able to just use a self-signed certificate in that case. This page might offer helpful guidance https://onionservices.torproject.org/apps/base/certificates/ Also, the SATA approach offers a header authenticated via the private key associated with the onion address that includes a hash of the TLS cert. It is intended for associating an onion address with a traditional (registered domain address) but might be adapted to this setting. That might also be worth exploring if the above runs into snags. But the above might be/lead-to what you need. OTOH sorry if I have yet again misunderstood. SSS, Paul
I could say a _lot_ about contextual trust and recognizing different authorities, but I'll stop myself and just assume for now that CAs, in particular Let's Encrypt, are sufficient authorities for your needs.
Easiest scenario one: You have some domain you can use, example.com, and you're OK getting certs to go with all the onion addresses you have. (Not sure of the limit, it was apparently at least 7 at one time. Cf. https://community.letsencrypt.org/t/subdomain-certificates/138733 )
Now get a TLS certificate from LE for example.com that includes the SANs [onion1].example.com, [onion2].example.com, etc.
You will need to be able to pass DNS or nonce checks or... that LE checks for example.com during issuance.
Once you have these, you no longer have maintain reachability at example.com
Will not discuss in this message how to use those certificates for (alleged) brevity.
Another scenario: You have a bunch of registered domain names at your disposal, example1.com, example2,com,..., examplen.com
You want credentials for onion addresses [onion1], onionm] where m \leq n
Now get a TLS certificate from LE for [onion1].example1.com another for [onion2].example2.com, etc.
You will need to be able to pass DNS or nonce checks or... LE checks for each [onioni].examplei.com during issuance.
Once you have these, you no longer have maintain reachability at the various examplei.com
Will not discuss in this message how to use those certificates for (alleged) brevity.
Another scenario: you just have one registered domain at your disposal, as in the first scenario, but you want to get (separate) certificates to multiple onion addresses
Follow same procedures as above scenarios, but for [onion1].sub1.example.com, [onion2],sub2.example.com, etc.
I don't know if any of these will work for you, The possible show-stopping assumption is if you don't have any registered domain at which you can offer connectivity even briefly just for certificate issuance. Hope this is a little clearer anyway.
SSS, Paul
On Tue, Jun 16, 2026 at 12:10:56PM +0100, techmetx11 wrote:
I feel like this would work if your service had a clear-web counterpart, but not much if you're just a onion-only service.
I was looking for something that is able to authenticate a onion service, regardless of what the service has (which doesn't have to be TLS auth if it can't, but ideally it should).
Given that the servers already have a custom certificate validation function (due to CAs like Let's Encrypt making it pretty difficult to have a signed certificate for client authentication), I was thinking I could put a onion service's key in a X.509 certificate, and check if the public key parsed from the onion service domain matches the public key in the certificate within the validation function.
I haven't managed to get that working though, unfortunately
On 6/11/26 1:21 PM, Paul Syverson wrote:
Hi techmetx11,
(Attempted resend since send from my Navy mail appearently failed to reach tor-dev. Apologies if you got this twice. -PFS)
I don't know if this fits what you need. But we have used the onion address as subdomain to put it into TLS certificates in the case where there is an associated domain name. E.g. Mullvad has a TLS certificate with the following SANs
o54hon2e2vj6c7m3aqqu6uyece65by3vgoxxhlqlsvkmacw6a7m7kiadonion.mullvad.net o54hon2e2vj6c7m3aqqu6uyece65by3vgoxxhlqlsvkmacw6a7m7kiadonion.www.mullvad.net/
We've used this in a couple of ways, for self-authenticating traditional addresses and for sauteed onions.
See e.g. https://arxiv.org/abs/2110.03168 and https://www.sauteed-onions.org/ Happy to talk more if asked about recent work on associating onion addresses with atproto handles as alternative/additional meaningful address.
In case it helps for your use case, note that you don't need to keep the service accessible at the registered domain address. It only has to be available during issuance (depending on the means of verification used).
You can also just get a certificate for an onion address. Issuance via ACME is still not available last I checked despite the efforts of Q Misell and others. Last I checked (some time ago) you can get a DV cert issued manually from HARICA or an EV cert from DigiCert.
The syverSAN technique OTOH works fine with Let's Encrypt issuance. Hope that helps.
Si sanus es, sanus sum, Paul
On 6/8/26, 4:32 AM, "techmetx11 via tor-dev" wrote:
Hi tor-dev mailing list,
Is there a way to capsulate a Tor hidden service Ed25519 private key inside a TLS EE certificate and use it in TLS?
I wanted to use this specifically for XMPP's server-to-server TLS connections, which uses mTLS to prove if the client connecting is who they say they are. Currently with XMPP Tor server-to-server connections, we have to use dialback (telling the server to connect back to the client to authenticate its identity, https://xmpp.org/extensions/xep-0220.html <https://xmpp.org/extensions/xep-0220.html>) to prove it, which is a legacy and insecure form of server-to-server authentication
If this is possible, then it would get rid of a reason to keep dialback around and less roundtrip for the server authentication.
Kind regards,
techmetx11
_______________________________________________ tor-dev mailing list -- tor-dev@lists.torproject.org <mailto:tor-dev@lists.torproject.org> To unsubscribe send an email to tor-dev-leave@lists.torproject.org <mailto:tor-dev-leave@lists.torproject.org>
tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-leave@lists.torproject.org
_______________________________________________ tor-dev mailing list -- tor-dev@lists.torproject.org To unsubscribe send an email to tor-dev-leave@lists.torproject.org
participants (2)
-
Paul Syverson -
techmetx11