[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #14389 [Core Tor/Tor]: little-t-tor: Provide support for better TBB UI of hidden service client authorization
#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:44 asn]:
> So, I guess the plan here is to use HTTP CONNECT for this, and define a
new error code for HTTP CONNECT that says that a destination needs client
auth. I guess we would need a proposal for that. Who wants to write this?
To me, the answer is "someone who can also take into account the other
error scenarios that we will need to address later, e.g., invalid onion
address and other onion-service related errors." Kathy and I don't think
we know enough to write a proposal.
On a related note, we have been experimenting with HTTP CONNECT inside tor
and Tor Browser over the past couple of days to determine if it is
workable from the browser side. We won't have time to work on this
tomorrow (Friday), so I am going to dump some notes here:
* If Torbutton is enabled, it does not work to use tor as an HTTP proxy.
Disabling Torbutton's domain isolation code allows it to work; more
investigation is needed.
* When HTTP and SSL proxies are configured, the Firefox code only uses
HTTP CONNECT for https requests. This probably matches traditional HTTP
proxy expectations, but it is not the behavior we need.
* To fix the above problem, we hacked Tor Browser to always include
`nsIProtocolProxyService::RESOLVE_ALWAYS_TUNNEL` in the proxy flags when
creating an HTTP channel. This change causes clear text http traffic to
also use HTTP CONNECT and therefore to be correctly routed through Tor.
* WebSockets traffic seems to go through the proxy as well (ws:// and
wss://).
* We are not sure what to do about other traffic, e.g., FTP. Our guess is
that due to the architecture of the Firefox networking stack, HTTP CONNECT
is only available for HTTP traffic. It might be difficult to ensure that
no proxy bypass possibilities are introduced if we switch to HTTP CONNECT.
* We would need to modify the browser code to add an `X-Tor-Stream-
Isolation header`.
* Does the `KeepAliveIsolateSOCKSAuth` isolation flag apply to
`HTTPTunnelPort` listeners?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/14389#comment:45>
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