[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #28181 [Core Tor/Tor]: spec: Add to pt-spec.txt control messages going back to main process (tor)

#28181: spec: Add to pt-spec.txt control messages going back to main process (tor)
-------------------------------------------------+-------------------------
 Reporter:  dgoulet                              |          Owner:  dgoulet
     Type:  enhancement                          |         Status:
                                                 |  assigned
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.6.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-spec, tor-pt, 036-roadmap-       |  Actual Points:
  subtask                                        |
Parent ID:  #28180                               |         Points:
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor8
-------------------------------------------------+-------------------------

Comment (by dcf):

 Thanks for working on this.

 Replying to [comment:5 dgoulet]:
 > What if instead we turn this around and keep the `EVENT` message idea so
 Tor can already start expecting such communication and future impl/spec
 will be able to use that to send anything back to Tor.
 >
 > But, we drop that `CONNECTION` event type that clearly doesn't work with
 all type of transport. Instead, we could have a simple `CONNECTIVITY` type
 which could report a binary state back to Tor saying "Ok I'm able to route
 traffic now as I connected to the endpoint and negotiated?".

 That's simpler and will work with more kinds of transports, but I'm afraid
 that some transports will just report `CONNECTIVITY OK` before doing
 anything, simply because they may not have anything to do until tor has
 given them something to send. Like in the case of meek, it doesn't try
 sending an HTTP request until it has some data to put in it. Potentially
 we could open the TCP connection to the web server and hold it idle until
 some data is available, but that would require breaking through a lot of
 HTTP library abstractions. In this case, we could try immediately sending
 an HTTP request with an empty body as a connectivity check, but in general
 that won't always work (and you would have to think about fingerprinting).

 Wouldn't this `CONNECTIVITY` message have the same semantics as the
 existing SOCKS success/failure messages? Those messages, too, make sense
 for connection-oriented transports like obfs4, but others can only send
 back a meaningless "success" message before even doing anything. E.g.,
 obfs4proxy, because it is connection-oriented, receives the SOCKS request,
 tries the TCP connection, then reports a SOCKS success/failure depending
 on the state of the TCP connection.
 https://gitweb.torproject.org/pluggable-
 transports/obfs4.git/tree/obfs4proxy/obfs4proxy.go?id=8256fac93c2cf79742725e3aaced5bbe3380fd32#n145
 Whereas meek simply reports SOCKS success unconditionally, because it
 can't do anything until tor has given it some data, and tor won't give it
 any data until it has reported SOCKS success.
 https://gitweb.torproject.org/pluggable-transports/meek.git/tree/meek-
 client/meek-client.go?id=8a5c6a9cdc4dc37ba77bb041ee48a4320689cc9d#n279

 > And we can also think that it could have an optional "ErrorMessage" in
 case it is a bad connectivity?
 >
 > Again, the goal here is to be able to make the PT tell Tor so Tor can
 tell the control port so ultimately Tor Browser can inform the user.
 Nothing more complicated for now.

 It would help if I understood what the purpose is from the tor side. What
 I imagine is that you want intermediate PT connection progress steps to be
 shown under the Tor Launcher status bar, i.e., some intermediate statuses
 between `BOOTSTRAP_STATUS_STARTING` and `BOOTSTRAP_STATUS_CONN_DIR`. I
 guess I could be wrong about that.

 How about this: transport plugins can send an `EVENT INFO <msg>` message
 that causes `<msg>` to appear in a user-visible status display, like Tor
 Launcher's status bar. And an `EVENT ERROR <msg>` that causes `<msg>` to
 appear in the user-visible display and in the tor log. Then PTs could
 report various kinds of messages, like
  * Establishing TCP connection
  * Registering with Snowflake facilitator
  * Connected to Snowflake proxy; currently have X out of Y desired
  * Connection lost to XXXX
 I guess there are localization problems if transports can report any free-
 form text; I'm not sure how tor currently deals with messages like
 "Establishing an encrypted directory connection".

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28181#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs