[tor-dev] Client identification for authenticated onions

[Shannon]

unsubscribe

Regards,
Shannon

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Tuesday, December 7th, 2021 at 9:21 AM, <yanmaani at cock.li> wrote:

> 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.
>
> tor-dev mailing list
>
> tor-dev at lists.torproject.org
>
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev