unsubscribe Regards, Shannon
Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, December 7th, 2021 at 9:21 AM, <yanma...@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@lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev