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 -- [email protected] > > > > > <mailto:[email protected]> > > > > > To unsubscribe send an email to [email protected] > > > > > <mailto:[email protected]> > > > > > > > > > > > > > > > > > _______________________________________________ > > tor-dev mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > _______________________________________________ > tor-dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ tor-dev mailing list -- [email protected] To unsubscribe send an email to [email protected]
