Hi,

> > Summary: the "Proxy-Authorization" header is (almost) never reset, and
> > the proxy doesn't like the header (for POST) after the authentication.
>
> Proxy-Authorization is meant to be repeated in every request since
> authentication is per request, not per connection. That's just how HTTP is
> designed and documented.
>
> This description of yours makes it sound to me as if this Negotiate is really
> NTLM behind the curtains, and googling for SPNEGO shows explanations
> filled with NTLM all over.
>
> Should Negotiate be treated more like NTLM rather than the "proper" auth
> methods?

Yes, they have a very similar 3 step authentication:
GET /... -> 407
GET /... + "Negotiate" -> 407 + "Challenge"
GET /... + "Auth" -> 200

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 (http://wiki.squid-cache.org/ConfigExamples/Authenticate/WindowsActiveDirectory#Install_negotiate_wrapper)

Now squid3 for example doesn't care about repeating the last "Auth" header, but the MS Proxy closes the connection (with a 407) if you repeat it in a POST request; that is why we need this fix.

> I rather not just glue in some "hackish" fix now when we don't even
> understand the auth protocol properly, nor do we have any tests to make
> sure old stuff keep working or that this won't regress in the future.

It can't be that "hackish", as you do the same for normal authentication :)

But ideally we would clean the header like it is done for NTLM (and similar for NTLM_WB) in https://github.com/bagder/curl/blob/master/lib/curl_ntlm.c#L217
- just this doesn't work reliably, as the authentication state is not attached to the connection and lives in the easy handle instead.
If you reuse the easy handle it will cleanup the header (for NTLM, and probably could be added for Negotiate); but if you make a new handle (or the connection gets moved to another handle), the header survives.

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.

Regards,
Stefan

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-10-22