Opened 9 months ago

Closed 8 months ago

#28275 closed defect (fixed)

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

Reported by: dgoulet Owned by:
Priority: Very High Milestone: Tor: 0.3.5.x-final
Component: Core Tor/Tor Version: Tor: 0.3.5.1-alpha
Severity: Normal Keywords: tor-doc, tor-hs, 035-must
Cc: Actual Points:
Parent ID: Points:
Reviewer: dgoulet Sponsor:

Description

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.

Child Tickets

Change History (13)

comment:1 Changed 9 months ago by haxxpop

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.

comment:2 Changed 9 months ago by 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.

comment:3 in reply to:  2 Changed 9 months ago by dgoulet

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.

comment:4 Changed 9 months ago by arma

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.

comment:5 in reply to:  4 Changed 9 months ago by haxxpop

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.

comment:6 Changed 9 months ago by dgoulet

Status: newneeds_information

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.

comment:7 in reply to:  6 Changed 9 months ago by asn

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?

comment:8 Changed 8 months ago by dgoulet

Status: needs_informationnew

comment:9 Changed 8 months ago by dgoulet

Keywords: tor-doc 035-must added; security removed

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.

comment:10 Changed 8 months ago by dgoulet

Reviewer: asn
Status: newneeds_review

Man page changes about this: ticket28275_035_01

comment:11 Changed 8 months ago by asn

Reviewer: asndgoulet

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

comment:12 Changed 8 months ago by dgoulet

Status: needs_reviewmerge_ready

comment:13 Changed 8 months ago by dgoulet

Resolution: fixed
Status: merge_readyclosed

Merged!

Note: See TracTickets for help on using tickets.