Re: [squid-users] HTTP/1.1 CONNECT truncating

From: Henrik Nordstrom <[email protected]>
Date: Tue, 15 Mar 2005 00:37:05 +0100 (CET)

On Mon, 14 Mar 2005, Louis Solomon [SteelBytes] wrote:

>> The CONNECT method is only designed for tunneling of SSL traffic via the
>> proxy, not other uses.
>
> can you please direct me to an RFC that supports these statements? as I
> believe otherwise.

Can you find any RFC indicating the opposite?

In Squid it is what it is designed for, and for good reasons security
wise. The CONNECT method in Squid is designed to be used by HTTP clients
wishing to do TLS/SSL connections, mainly HTTPS.

It is even questionable if the CONNECT method even belongs in HTTP proxies
at all designwise but that is another story and is the reason why the
CONNECT method is barely mentioned in the HTTP or even HTTPS standards
(only briefly in RFC2616 (HTTP, Draft Standard), and then defined but not
for the current use in RFC2817 (TLS within HTTP, Proposed Standard)).
RFC2818 (HTTP over TLS, aka https, Informational, Not a standard) doesn't
even mention it which strikes as a bit odd given that this is the most
common use of the CONNECT method.

If you want a generic end-to-end TCP proxy then SOCKS should be used.

> from rfc 2616 http/1.1:
> "9.9 CONNECT This specification reserves the method name CONNECT for use
> with a proxy that can dynamically switch to being a tunnel (e.g. SSL
> tunneling [44])."

The correct reference these days defining CONNECT is RFC2817 published by
the TLS workinggroup within the networking area of IETF. But on careful
reading of this document Squid does not quite implement things correctly
from being optimized to handle SSL/TLS tunneling. According to the RFC it
should flush pending data on disconnect to the other endpoint but
currently it discards any pending data if the client side disconnects.

Please file a bug report on this issue and we may fix it. I still consider
this use of the CONNECT method an abuse of the HTTP proxy however and you
would be much better using SOCKS or a protocol specific proxy.

Regards
Henrik
Received on Mon Mar 14 2005 - 16:37:07 MST

This archive was generated by hypermail pre-2.1.9 : Fri Apr 01 2005 - 12:00:02 MST