[tor-dev] Client identification for authenticated onions

[yanmaani at cock.li]

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 
> username+password
> 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 
> with
> 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 
reasons".

> 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 
> anyway.

That's not great for the network.