hs-v3: Rotate intro points and close RP circuits when removing client auth service side

On the service side (only), when a client authorization is removed and then tor is HUP, right now the service notices that and re-upload a new descriptor containing that new auth.

However, the into points are most likely kept as is (if no normal rotation happened during re-build) which means that a revoked client can still access the service with their cached descriptor because the intro points are still valid...

Furthermore, the RP circuits for that client aren't closed.

Security wise, that is not ideal to have a "not really revoked client" ;). Fortunately, only applies to 0.3.5.1-alpha and onward so no need for a TROVE.

changed milestone to %Tor: 0.3.5.x-final

added 035-must component::core tor/tor milestone::Tor: 0.3.5.x-final priority::very high resolution::fixed reviewer::dgoulet severity::normal status::closed tor-doc tor-hs type::defect version::tor 0.3.5.1-alpha labels

Since we cannot close only some RP circuits, we need to close all RP circuits or not close them at all.

If we close all the circuits, all the clients will know that torrc is reloaded. If we don't close them at all, we don't have a real client revocation.

Another option is to have a torrc option to let the service owners decide by themselves.

Also rotating all the intro points will mess up clients that have the existing descriptor (and intro points) cached, right? Imagine an onion service with a pile of clients who are authorized to reach it, but that keeps rearranging its set of acceptable clients, in an automated way, due to some policy it has. If it keeps shifting its intro points at each change, it could really undermine its reachability.

Replying to arma:

Also rotating all the intro points will mess up clients that have the existing descriptor (and intro points) cached, right? Imagine an onion service with a pile of clients who are authorized to reach it, but that keeps rearranging its set of acceptable clients, in an automated way, due to some policy it has. If it keeps shifting its intro points at each change, it could really undermine its reachability.

Yes and this becomes even more annoying if we close all RP circuits (because service doesn't know which circuit is which client) every time a client is removed from the configuration...

But I still think that there has to be some assumption from an operator that once the client auth has been removed, after the HUP, that client CAN NOT have access to the service. Equivalent of a tor restart basically.

For the "cutting all RP circuits" side, compare to how we handle changes in ExitPolicy, or how we handle changes to SocksPolicy: the config change only impacts how we respond to new requests. That is, we don't cut existing exit connections when the exit policy changes, or existing socks connections when the socks policy changes. As an even more extreme example, I think we leave OR and exit connections as-is when ORPort gets disabled too. All of these config options focus on how we will treat new requests.

As for the "rotating intro points" side, I haven't kept up on the auth design here, but I just looked through rend-spec-v3.txt. It looks like there are two components to the client auth -- one is whether the client can decrypt the descriptor (to learn the intro points), and the other is whether the client can prove that it's authorized in the INTRODUCE1 cell? I'm tempted to try to solve this one by defining "revoke" to focus on that second component. I also wish we had actual use cases for this client auth design, so we wouldn't be left trying to debate over what future hypothetical users would want the system to do.

Replying to arma:

one is whether the client can decrypt the descriptor (to learn the intro points), and the other is whether the client can prove that it's authorized in the INTRODUCE1 cell? I'm tempted to try to solve this one by defining "revoke" to focus on that second component. I also wish we had actual use cases for this client auth design, so we wouldn't be left trying to debate over what future hypothetical users would want the system to do.

We previously had a discussion about that second component in the INTRODUCE1 cell. By that time, we decided to not implement it (and probably will never) because the only benefit of INTRODUCE1 authorization is to let the service know which client it is connected to and then the service can serve different services for different clients.

But that can be implemented easily in the application layer and the feature is not related to anonymity (not related to Tor). So we thought we don't need to implement it at all.

I'm fine with not closing all RP circuits as long as we document it properly and that the solution for "really revoking" a client would be to restart tor in this case.

As for rotating intro points, old descriptor can still connect if we don't meaning that all "new" requests like arma mentions will still work.

However, the reachability impact is pretty strong especially if the service does that every let say 5 minutes... Again, we could simply document that if you want the "really revoking" access, then restart tor.

Trac:
Status: new to needs_information

Replying to dgoulet:

I'm fine with not closing all RP circuits as long as we document it properly and that the solution for "really revoking" a client would be to restart tor in this case.

As for rotating intro points, old descriptor can still connect if we don't meaning that all "new" requests like arma mentions will still work.

However, the reachability impact is pretty strong especially if the service does that every let say 5 minutes... Again, we could simply document that if you want the "really revoking" access, then restart tor.

Sounds good to me. Perhaps we can even add a log msg warning the user if a client was revoked?

Trac:
Status: needs_information to new

This has become a documentation issue that is mentioning that if you remove a client from the client authorization list, the real way to revoke its access is to restart the service.

Sounds good to me. Perhaps we can even add a log msg warning the user if a client was revoked?

Right now, tor can't differentiate between a client that is removed vs a client added. The change would require some work for this logic thus we can't log a warning "only on removal" for now.

It doesn't prevent us I guess to have a notice (would probably limit it to only once) there regardless of an addition or removal on how to really revoke a client that is restarting tor.

Trac:
Keywords: security deleted, tor-doc, 035-must added

Man page changes about this: ticket28275_035_01

Trac:
Reviewer: N/A to asn
Status: new to needs_review

Counterproposal in my ticket28275_035_01 branch: https://github.com/torproject/tor/pull/562

Trac:
Reviewer: asn to dgoulet

Trac:
Status: needs_review to merge_ready

Merged!

Trac:
Resolution: N/A to fixed
Status: merge_ready to closed

closed

mentioned in issue #28358 (moved)

moved to tpo/core/tor#28275 (closed)