Re: [tor-bugs] #14389 [Core Tor/Tor]: little-t-tor: Provide support for better TBB UI of hidden service client authorization

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#14389: little-t-tor: Provide support for better TBB UI of hidden service client
authorization
-------------------------------------------------+-------------------------
 Reporter:  asn                                  |          Owner:  tbb-
                                                 |  team
     Type:  defect                               |         Status:
                                                 |  needs_revision
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.4.2.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-hs, tbb-usability, ux-team, hs-  |  Actual Points:
  auth                                           |
Parent ID:  #30000                               |         Points:  14-24
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor27-must
-------------------------------------------------+-------------------------

Comment (by mcs):

 Replying to [comment:46 asn]:
 > Thanks for digging into this! From the above issues, only this one about
 proxy bypass seems to be blocker to me. All the others are things that can
 be solved with some moderate engineering efforts IIUC. However, if we
 can't guarantee that we have no proxy bypass we can't really proceed with
 HTTP CONNECT, right? What do you think?

 I think there are a bunch of issues that add up to a lot of work, and each
 one carries some associated risk.  Obviously potential proxy bypass would
 be a very important risk to address.

 Over the past few days, Kathy and I have been thinking in general terms
 about the implications of a switch from SOCKS to HTTP CONNECT. There is an
 architectural difference inside the browser network code that seems
 important: the SOCKS layer in Firefox is located near the bottom of the
 networking stack, but HTTP CONNECT is a special thing that is supported
 for HTTP and WebSockets only. And HTTP CONNECT previously has only been
 used for WebSockets and proxying of https:// requests inside Firefox.

 To us, the big issue is that if Tor Browser uses HTTP CONNECT in a way
 that the Firefox networking engineers did not design for and/or do not
 expect, we will have trouble now and in the future.  It seems like a
 risky change, and it may take a lot of time for the browser team to
 resolve all of the issues associated with it.  Patching the Firefox code
 to meet our needs will also add to our ongoing maintenance burden
 (although we would try to get Mozilla to accept our patches). Finally,
 this is the kind of work we should defer until after we transition the
 browser to an ESR68-based codebase, and that work won't be finished until
 approximately October 2019. For all of these reasons, Kathy and I would
 prefer to find a way to continue to use SOCKS and find a different way to
 pass additional error information from tor to the browser (either via
 control port events or via additional SOCKS error codes, or some
 combination of the two).

 Georg reminded me earlier today that the browser already successfully
 associates asynchronous control port events with browser tabs for the
 circuit display. Kathy and I will take a fresh look at that code to see
 how it works.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/14389#comment:47>
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