Minor security bug with tor authorized_clients

Ive been developing a hidden service that relies on the 25519 Public/Private Key Pair to authorize clients. It works in that I can add a public key to the server and from the tor browser enter the private key and get access. However, When I tried to revoke access by removing the public key from the server, the client can still access the server.

Steps

  1. create key pair and put public key file in hidden service authorized_clients directory and restart/reload tor.

  2. Connect with tor browser, enter private key when prompted.

  3. Access service.

  4. Remove public key from authorized_clients directory and restart/reload/stop and start service. (tried all 3)

  5. access from client still works.

  6. reload client, still has access.

The only time I lost access was when I removed the private key from the tor browser. Then it could no longer access the service.

When someone’s public key is removed from the hidden service they should no longer be able to access the service.

Why did this get moved here? It is an issue with the little-t-tor service. It does not actually validate the public key auth file in authorized_clients for the hidden service. It just lets anyone in if they have a private key that the client says is for the service.

Meaning the whole client-auth subsystem is broken and not working correctly.

(edit: corrected spelling)

Thank you for moving it to the correct area.

1 Like

Yes, this is the expected behavior, but I don’t think this is going to always happen instantly.

When you restart (or maybe when you just reload) the service, we expect that an updated descriptor is published in the HSDirs, without the client authorization corresponding to the removed key.

But if the client still have the previous descriptor in the local cache, and the introduction points for the service are still the same, I suppose it can still connect to the service.

On C Tor, in theory this shouldn’t happen if you restart the service (since there’s no state persistency for Onion Services, as far as I know). Not sure about reloading.

For Arti, the situation might be different, as introduction points [are] part of an onion service’s persistent state (#967).

In summary, in order to remove the old client from the service access, I believe the service also need to change it’s introduction points. Implementations might differ here in what needs to be done to trigger intro point rotation.

Did you test with Arti[1] or C Tor? From your description, it seems C Tor, but it’s puzzling that a restart does not properly removes the client from the authorization.


  1. Arti recently got support for client authorization (now called restricted discovery), so maybe also worth testing. ↩︎

1 Like

So are you suggesting that I would have to do a signal newnym and build a new circuit for it to stop allowing it?

There is nothing about that in the documentation

Sorry, adding that Im running c-tor (Linux based systems)

I have asked around, and restricted discovery is not considered “real authorization” – it does not have all the required guarantees for such a system (and that’s why made sense to rename it from “client auth”). It’s mainly a best effort prevention for unauthorized access, plus an additional DoS defense.

An improved mechanism is discussed at tpo/core/arti#1028.

There is nothing about that in the documentation

Yes, you’re right, and we’re planning to fix this: Update "client authorization" documentation with new terminology (#261) · Issues · The Tor Project / Onion Services / Onion Support · GitLab

So are you suggesting that I would have to do a signal newnym and build a new circuit for it to stop allowing it?

I don’t think that NEWNYM actually updates the introduction points for an Onion Service. It seems mostly used to clear the local DNS cache and circuits on clients.

A daemon restart on C Tor should have handled the rotation of introduction points (since C Tor does not keep intro point state), but there a small chance that services actually picks the same intro points from the previous run. Maybe that what happened to you, or maybe there’s really a bug somewhere…

I have asked around, and restricted discovery is not considered “real authorization” – it does not have all the required guarantees for such a system (and that’s why made sense to rename it from “client auth”). It’s mainly a best effort prevention for unauthorized access, plus an additional DoS defense.

I think we are on the same page here. Im using it simply to control the ability for a client to connect to the service. You can read the about page HERE

I don’t think that NEWNYM actually updates the introduction points for an Onion Service. It seems mostly used to clear the local DNS cache and circuits on clients.

My understanding is that NEWNYM creates a new tor circuit for the server. Is that incorrect?

A daemon restart on C Tor should have handled the rotation of introduction points (since C Tor does not keep intro point state), but there a small chance that services actually picks the same intro points from the previous run. Maybe that what happened to you, or maybe there’s really a bug somewhere…

Ive tried restarting the service multiple times and even changing the VPN exit point to another country. So it is looking more like a bug.

I wouldn’t count on that.

As far as I know, NEWNYM is mostly intended for applications such as Tor Browser to provide a “new identity” for users (i.e, new circuits and a clean DNS cache).

For Onion Services, even if NEWNYM did generate new circuits, I think those would still be established to the same set of intro points.

Ive tried restarting the service multiple times and even changing the VPN exit point to another country. So it is looking more like a bug.

Yes, that’s strange. Even if there’s a bug, fixing it would still be only short term, as Arti behaves differently here anyway.

This seems to be implementation-dependent and there’s no guarantee about the behavior your application depends, so this use case may break in the future.

What you may be looking for is an enhanced authentication mechanism: