#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@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
