Re: Chained proxies, persistent connections, authentication

On Fri, 2003-10-24 at 06:50, Duane Wessels wrote:
> > I don't recall how it was determinted that Proxy1 was forwarding proxy
> > authentication headers to Proxy2. Sans a tcp/ip trace or comprehensive
> 
> FYI, this is a feature of Squid.  An admin can configure Squid to
> forward the Proxy-Authorization header (without consuming it).
> 
> I would suggest that in this particular case, since both Squid and
> "proxy2" are breaking the rules, the problem is solvable by disabling
> server-side persistent connections in Squid.

Finally got time to contribute to the thread. Firstly, rfc 2616 14.34
allows squids behaviour in forwarding the authentication details.

The ntlm/kerberos tcp session based authentication used by MS proxies
(and squid has an option in 2.5 and above) isn't compatible with the
base HTTP spec. However there is an expired I-D (one url for it is 
http://216.239.57.104/search?q=cache:Fcb67r9QFF4J:www.globecom.net/ietf/draft/draft-brezak-spnego-http-03.html+SPNEGO+http+draft&hl=en&ie=UTF-8)
the draft was brezak-spnego-http.

That draft described a new header "Proxy-support:
Session-Based-Authentication" for proxies to use to indicate to clients
that they support the connection semantics needed to operate correctly
with such upstream servers (proxies where not documented, but we've
found MSIE uses the same mechanism with proxies as servers, insofar as
the authentication is concerned - we haven't tested the proxy-support
header.

Squid doesn't issue the Proxy-support header, and if (as it should be)
it's listed in the connection header by the upstream proxy, then squid
would strip it. However, as we don't support the connection semantics to
use NTLM or kerberos through squid, in recent squid 2.5 releases we
filter the incompatible authentication headers.

So, I'd suggest that the user has an older squid release, as a newer
release wouldn't show these symptoms.

Rob

-- 
GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.