[tor-dev] Client identification for authenticated onions
yanmaani at cock.li
yanmaani at cock.li
Mon Nov 1 09:34:25 UTC 2021
On 2021-08-23 20:56, cho8jeiv4aus at paperboats.net wrote:
> Hi there. I had an idea recently for an onion service to improve the UX
> of sites that require a login. The site would have two onions: one for
> those who want to use onion auth and another for those who don't or are
> still setting it up. A user would first sign in with a
> on the unauthenticated onion and click a button to generate a
> certificate associated with their account. Then they would add the
> public key to their browser and visit the authenticated onion. The
> application server would then match the pubkey used to authenticate
> an account in the database, and log them in automatically.
As for your case, you could maybe try client-side TLS certificates.
I've had a similar idea for DoS protection. You have two onions, call
them "open" and "closed".
In the good times, you go to the "open" onion and register. It gives you
a client authentication password for "closed" and redirects you there.
On subsequent logins, you just go straight to the "closed" onion. (In
theory, it's enough to have the key get you to the login screen - it
doesn't actually have to replace authentication)
Then, when the attack comes, it will take down the "open" onion.
However, the "closed" onion is protected by client auth, and can be
rate-limited by key.
The only thing that would be needed for this is a special version of
client authorization that allows the server to see *which* key is
connecting, as opposed to "some key but you don't know which for privacy
> As an operator, an alternative would be to generate one (authenticated)
> onion service per user and route them all to the same place with
> different Host headers, but that seems rather inefficient, and I don't
> know how well the tor daemon scales up to hundreds of onion services
That's not great for the network.
More information about the tor-dev