> > * Not reusing easy handles (curl_easy_reset) basically breaks anything
> > related to (proxy) authentication.
>
> Can you please back this up with test cases that don't use Negotiate or
> NTLM?
> Our test suite works perfectly fine for such cases so it should be easy to
> repeat and then we can work on making this working in case of bugs.

I remember having seen the same Digest proxy-authentication header (i.e. counter didn't get increased). Sometimes the proxy accepted it, sometimes it didn't.

If I find the time I'll try to provide a test case.

> I still believe you're mostly hanging on to side-effects and/or are seeing
> bugs (mostly related to the Negotiate mess), not finding actual conceptual
> flaws in either of the functions. And you haven't backed up your claims with
> proofs either I think.

I'm just going to turn this around: if you think they behave the same, proof it :)

I saw they did not; and the cleanup + init behavior was not acceptable to us, so we went with reset instead. (And yes, this was also the case for Digest authentication, not just NTLM or Negotiate)

As long as you keep the authentication state (say Digest) in the easy handle and not the connection, it will always be a performance problem not to reuse the easy handles (I hope we can agree on that); it would be nice if this was obvious from reading the documentation.

> > From a security point of view you are screwed anyway with multi
> > handle; if you reuse a connection which was authenticated (NTLM or
> > Negotiate) in a new handle you inherit the credentials, whether you
> > passed them again or not.
>
> Nope. We only re-use NTLM connections that have matching credentials. If
> not, there's another bug. We've had such bugs in the past.

Afaics you only compare the normal credentials, not the proxy credentials.
 
> > (And right now you also inherit the Basic and Digest proxy
> > authentication headers; Basic will continue to work, and Digest often
> > works more than
> > once.)
>
> Basic and Digest state lives in the easy handles. They can change
> connections and continue using HTTP auth.

Yes, but the Authentication header lives on in the connection (point 2 in my previous mail).

> > * curl does an unneeded additional round-trip for authentication:
> > in the first round it iterates over the available authentication
> > headers, then picks one - but doesn't actually handle the header.
> > It then sends a new request before actually handling the header;
> > instead it should iterate over the headers from the first request
> > again.
>
> I don't think I understand this case. Can you elaborate a bit more perhaps
> with some real data to show?

Ah, this is not a problem with Basic (doesn't need the header) and Digest (which doesn't wait to get picked as the comment in lib/http.c:852 says).
Both NTLM and Negotiate do wait to get picked (lines 782 and 806).

So trying anyauth against NTLM or Negotiate should show the problem.

> > I extended my patch for headers (point 1) to also fix point 4 and 5 in
> > the list above, and I'd like to get some feedback; especially whether
> > this:
> >
> > bool proxy_connect_auth = (0 == http->writebytecount) &&
> > (!conn->bits.protoconnstart);
> >
> > is a correct way to detect whether we are currently proxy-
> > authenticating a CONNECT
>
> Isn't conn->tunnel_state[sockindex] better for that? Or
> data->state.authproxy.done ?

Can you give a complete example for that line?

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