curl-library
RE: Problem with NEGOTIATE-Proxy-Authentication and not reusing underlying TCP-Connections
Date: Thu, 23 Oct 2014 08:55:07 +0000
Hi,
> > And afaict both authenticate the connection (both squid3 and MS Proxy
> > work that way) and not the request. Negotiate is basically a wrapper
> > around NTLM that also supports Kerberos; squid3 contains a
> > negotiate_wrapper that takes a NTLM and a Kerberos authenticator
>
> It is that two different actual protocols thing that has kept me confused,
> because Kerberos authentication should be possible to do on a per-request
> basis while NTLM is a per-connection thing. I'm now thinking that Negotiate
> perhaps always have to be considered to be per-connection for it to work
> properly.
>
> This of course requires some adjustments in the code to make it so.
I didn't get around to test Kerberos yet, so maybe Negotiate+Kerberos works per request :)
> > So: IMHO the header should always be cleaned up, and the
> > authentication states should be moved to the connection state; because
> > Digest will break even with this patch, as you need the counter -
> > Basic auth ofc works if you don't cleanup the header.
>
> HTTP authentication is not associated to the exact TCP connection so it
> cannot always be stored on a per-connection basis. HTTP and libcurl can
> keep the authenticated state even when creating new connections to
> continue on.
>
> Connection-based authentication methods are violators of the HTTP spec
> and thus we handle them separately from the "normal" ones. We need to
> start handling Negotiate as we handle NTLM I guess.
I still think the current Digest behaviour is broken too; curl_easy_cleanup + curl_easy_init shouldn't behave differently than curl_easy_reset, but the former destroy the Digest state and the latter keeps it (you can throw away the credentials ofc, as they should be provided in the next request again; but you want to keep the challenge/counter/...).
Basic proxy-authentication just happens to work because it reuses the previous proxy-authentication header, but it doesn't look like it is on purpose - I'm pretty sure the internal flags don't represent the "we just did Basic auth".
So I think the best way would be to throw away the proxy-authentication header the same way as the normal header (without switch and special cases), and keep the authentication state in the connection.
Some authentication states could be shared across connections ofc (i.e. Digest), but that might require more work.
Regards,
Stefan
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-10-23