Opened 4 years ago

Last modified 2 years ago

#17120 new enhancement

Fire a circuit status control port event when circuit isolation changes.

Reported by: yawning Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: port, easy, lorax, tor-control, needs-design, isolation
Cc: atagar Actual Points:
Parent ID: Points: small/medium
Reviewer: Sponsor:

Description

Followup from #17086.

Currently trying to track circuit isolation status via control port events is non-trivial/impossible without polling due to predictive circuits and other non-SOCKS initiated circuits being used to service SOCKS requests.

The current behavior is correct according to the control port spec, since the username/password are only provided when the circuit was initiated via a SOCKS request, and is silent about BUILT circuits being used to immediately service a request.

This *should* be easy to do, but requires a control spec change and is an enhancement so it's a 0.2.8.x thing at the earliest.

Child Tickets

Change History (14)

comment:1 Changed 4 years ago by cypherpunks

The isolation should be reported in stream events. This can easily be done by adding new optional fields and should not break existing controllers.

As an added benefit, custom controllers will be able to perform stream isolation. They can't right now, since the isolation parameters are only reported in circuit events when it is too late.

The stream events should include SOCKS address:port of the listener side of the Tor side of the socks connection and SOCKS username/password.

(SOURCE_ADDR currently included in stream events is the wrong/useless side of the socks connection.)

comment:2 Changed 4 years ago by yawning

Keywords: lorax added

Sounds reasonable. There's no particular reason why both can't be done, and imo both should be (I view circuit isolation changing as a circuit status change, so an event should be fired...).

This is not something that I will be getting to anytime soon so other people should feel free to take it, though I'll probably revisit it once 0.2.8.x development starts in earnest.

comment:3 Changed 4 years ago by nickm

Keywords: 028-triaged added

comment:4 Changed 4 years ago by nickm

Sponsor: SponsorS

comment:5 Changed 4 years ago by nickm

Points: small/medium

comment:6 Changed 4 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.???

Move a bunch of (but not all) low-priority items to 0.2.???. If you write a patch, it can still get into 0.2.8

comment:7 Changed 3 years ago by nickm

Keywords: SponsorS-deferred added
Sponsor: SponsorS

Remove the SponsorS status from these items, which we already decided to defer from 0.2.9. add the SponsorS-deferred tag instead in case we ever want to remember which ones these were.

comment:8 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:9 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:10 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:11 Changed 2 years ago by nickm

Keywords: 028-triaged removed

comment:12 Changed 2 years ago by dgoulet

Keywords: tor-core removed

The tor-core keyword doesn't really make sense now that we have "Core Tor/Tor" for component.

comment:13 Changed 2 years ago by dgoulet

Keywords: tor-control added; control removed

Unify "control" keyword to "tor-control".

comment:14 Changed 2 years ago by nickm

Keywords: needs-design isolation added; SponsorS-deferred removed
Severity: Normal
Note: See TracTickets for help on using tickets.