Re: [tor-bugs] #22407 [Core Tor/Tor]: Support HTTP CONNECT tunnels as an alternative to SOCKS

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

#22407: Support HTTP CONNECT tunnels as an alternative to SOCKS
-------------------------------------------------+-------------------------
 Reporter:  nickm                                |          Owner:
     Type:  defect                               |         Status:  new
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  unspecified
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-client pt-v2 application-        |  Actual Points:
  support http-connect needs-design prop229      |
Parent ID:                                       |         Points:  5
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by nickm):

 Replying to [comment:6 cypherpunks]:
 > HTTP CONNECT also supports authentication, which can be used in place of
 SOCKS' password authentication, which Tor uses for isolating circuits.
 It's implemented simply as an HTTP header, which the RFC shows with the
 example header `Proxy-Authorization: basic aGVsbG86d29ybGQ=`. To the best
 of my knowledge, HTTP CONNECT supports all features which Tor uses from
 SOCKS proxies, so no strange hacks would be required to permit full usage
 of this protocol. It is a very simple protocol (when the CONNECT method is
 the only one implemented), so it can be made very simple and secure.

 So, I think that instead of just overloading proxy-authorization here, it
 might make more sense to allocate an additional header for applications
 that are tor-aware.  One of the nice things about HTTO CONNECT is that we
 can add new headers rather than overloading ones that already existed.

 > In terms of difficulties I get when using Tor, I'd say that the lack of
 HTTP proxy support is in my top 5 grievances. It is not pleasant needing
 to use the ugly hack that is libtorsocks to hook (and often break) a
 program that fully supports HTTP proxies. As the OP stated, this shouldn't
 be a complex, caching, featureful "secure HTTP proxy", but just a simple
 alternative to `SOCKSPort`.
 >
 > Are there no objections to the spirit of this ticket, making actual
 implementation and discussion of specific behavior the only thing holding
 this back?

 I think that a design for the behavior and the actual implementation are
 the only things I'm aware of.

 One thing that a design has to take into account is to make sure that this
 won't open up any exciting new security holes from a local non-tor-aware
 web browser running hostile pages.  But I think that shouldn't be pretty
 hard -- it's just that the argument should be explicit.

 The implementation should probably be written to add a new client
 connection type, HTTPConnectPort, in the style of SOCKSPort.  It can share
 most of the implementation with socks connections, except that instead of
 entering AP_CONN_STATE_SOCKS_WAIT on construction, it should enter a new
 state, AP_CONN_STATE_HTTP_CONNECT_WAIT.  It can probably use the existing
 fetch_from_buf_http() implementation (possibly with small inputs) to parse
 its implementation.

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