[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-dev] Re: Using hidden service key with TLS client authentication
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@xxxxxxxxxxxxxxxxxxxx <mailto:tor-dev@xxxxxxxxxxxxxxxxxxxx>
> > > > > To unsubscribe send an email to tor-dev-leave@xxxxxxxxxxxxxxxxxxxx <mailto:tor-dev-leave@xxxxxxxxxxxxxxxxxxxx>
> > > > >
> > > > >
> > > > >
> > _______________________________________________
> > tor-dev mailing list -- tor-dev@xxxxxxxxxxxxxxxxxxxx
> > To unsubscribe send an email to tor-dev-leave@xxxxxxxxxxxxxxxxxxxx
> _______________________________________________
> tor-dev mailing list -- tor-dev@xxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to tor-dev-leave@xxxxxxxxxxxxxxxxxxxx
_______________________________________________
tor-dev mailing list -- tor-dev@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to tor-dev-leave@xxxxxxxxxxxxxxxxxxxx