[tor-dev] Re: Using hidden service key with TLS client authentication

[techmetx11 via tor-dev <tor-dev@xxxxxxxxxxxxxxxxxxxx>]

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