Opened 5 months ago

Closed 6 weeks ago

#22407 closed defect (implemented)

Support HTTP CONNECT tunnels as an alternative to SOCKS

Reported by: nickm Owned by: nickm
Priority: Medium Milestone: Tor: 0.3.2.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-client, pt-v2, application-support, http-connect, needs-design, prop229
Cc: adrelanos Actual Points:
Parent ID: Points: 5
Reviewer: isis Sponsor:

Description

Note: This is NOT a ticket about adding a caching or rewriting or privacy-enhancing HTTP proxy to Tor.

We may want to support the "HTTP CONNECT" command as an alternative to SOCKS, since a fair number of applications support the former but not the latter. For the current definition of HTTP CONNECT, see RFC 7231.

Our existing HTTP parsing code should be sufficient to handle these requests, though we would want to make sure we got the semantics right.

The flexibility of HTTP could make this an alternative to proposal 229.

Child Tickets

Change History (20)

comment:1 Changed 5 months ago by nickm

Component: - Select a componentCore Tor/Tor
Milestone: Tor: unspecified

comment:2 Changed 5 months ago by nickm

This ticket is a partial resurrection of #6060, which got pretty confused.

comment:3 Changed 5 months ago by adrelanos

Cc: adrelanos added

comment:4 Changed 5 months ago by nickm

Closed #10848 as a duplicate of this.

comment:5 Changed 5 months ago by ben

Normally, the new bug is closed as DUP of the old one. #10848 is clearly stated, and clean.

comment:6 Changed 3 months ago by 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.

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?

comment:7 in reply to:  6 Changed 3 months ago by nickm

Replying to 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.

comment:8 Changed 3 months ago by nickm

Oh and of course, we should fuzz the living heck out of this :)

comment:9 Changed 2 months ago by nickm

Milestone: Tor: unspecifiedTor: 0.3.2.x-final
Owner: set to nickm
Status: newaccepted

I'm supposed to be on vacation, but I got bored and wanted to give this a try.

There's a rough (under-documented, under-tested, but works for me with curl) implementation in my branch http_tunnel.

comment:10 Changed 2 months ago by nickm

(not putting this in needs_review till the branch is better.)

comment:11 Changed 2 months ago by nickm

Status: acceptedneeds_review

okay, I've fixed the obvious problems. It still needs a changes file and some manpage entries, but before I write those, I'd like opinions on the vocabulary, option names, etc.

comment:12 Changed 2 months ago by nickm

Keywords: review-group-22 added

comment:13 Changed 8 weeks ago by nickm

I've also put it on oniongit at https://oniongit.eu/nickm/tor/merge_requests/6

comment:14 Changed 8 weeks ago by nickm

Reviewer: isis

comment:15 Changed 8 weeks ago by isis

Status: needs_reviewneeds_revision

Reviewed on oniongit. There's a couple suggestions/comments but nothing major, so please feel free to address whatever comments you feel like and then merge.

comment:16 Changed 7 weeks ago by nickm

Status: needs_revisionneeds_review

I've added documentation and a fuzzer, and responded to the rest of the comments. I'm hoping to learn more about good behavior for the error codes, but I suspect it's an under-written area of the RFCs. Any thoughts?

comment:17 Changed 7 weeks ago by nickm

Merging what we have so far, but leaving this open until I open tickets for the remaining issues

comment:18 Changed 6 weeks ago by nickm

Keywords: review-group-23 added

Put 0.3.2 needs_review and merge_ready tickets into review-group-23.

comment:19 Changed 6 weeks ago by nickm

Keywords: review-group-22 review-group-23 removed

comment:20 Changed 6 weeks ago by nickm

Resolution: implemented
Status: needs_reviewclosed

Opened #23438; closing this ticket.

Note: See TracTickets for help on using tickets.