[tor-dev] Dormant Mode and pluggable transports

[David Fifield <david@xxxxxxxxxxxxxxx>]

On Thu, Dec 13, 2018 at 03:56:50PM -0500, Nick Mathewson wrote:
> == Compatibility issues
> 
> I see two issues here: one minor, and one major.
> 
> Minor issue: some applications periodically make requests to the tor
> network on their own -- for example, Tor Browser's update requests.
> These requests prevent Tor from becoming dormant.  If this is
> undesired, we can add some way around this.
> 
> Major issue: some applications expect that Tor will always bootstrap
> when it starts, and delay presenting their own UI until Tor is ready.
> But if Tor starts as dormant, then it will not bootstrap until it
> receives a request from the client or a "SIGNAL ACTIVE"  command from
> the controller. This could lead to breakage as the application waits
> for Tor to tell it that it's ready, and Tor waits for somebody to tell
> it that it's needed.
> 
> Are all application developers okay with the issues above, and okay
> with working around them?  If not, we may need changes in Tor before
> 0.4.0.x is released.  Let's talk!

I'm thinking about how Dormant Mode will interact with pluggable
transports. Our current transports will (I think) become dormant when
tor does, because they only send something when tor does. At most, they
may chop up and pad some of tor's packets (like obfs4 iat-mode does),
but they don't send traffic of their own while tor is quiet. There's
nothing requiring that though: a transport is in general free to send
dummy traffic whenever it wants, perhaps as a form of traffic flow
obfuscation.

If transports need to become dormant too, then there needs to be some
way for tor to tell them to be. Now that https://bugs.torproject.org/28179
(Handle output from PT processes with the event loop) is almost
finished, perhaps the stdin/stdout channel would work for it. A request
to become dormant really does apply to the entire PT process (not just a
single transport or connection), so it's a good match for a
process-global channel like stdin. The PT process could respond with a
"SIGNAL DORMANT" message on its stdout, which would inform tor that the
PT has understood the request and will try to become dormant.

Or simpler but more drastic, tor could terminate its PT subprocesses
when it goes dormant (cleanly, by closing their stdin).
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev