Client identification for authenticated onions
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. I've looked in the mailing list archives and `man 1 tor` but didn't find anything that would facilitate this. The closest, it seems, is HiddenServiceExportCircuitID, but that is for *circuit* IDs, not *client* IDs. Is this possible to implement, either as an operator or as a Tor developer? 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. P.S. I didn't find an easy way to do full text search on the mailing list archives, so I wrote a little script to download them all. I've attached it in case it ends up useful. It requires python3.8+ and you'll need to `pip install aiohttp anyio BeautifulSoup4` first. After that you can run `./pipermail_fetch.py https://lists.torproject.org/pipermail/tor-dev/` and then something like `rg --context 3 --search-zip '^[^>].*search term here'` will do the trick.
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.
unsubscribe Regards, Shannon Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, December 7th, 2021 at 9:21 AM, <yanmaani@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
participants (3)
-
cho8jeiv4aus＠paperboats.net -
Shannon -
yanmaani＠cock.li