On Fri, 13 Jun 2003 04:44 pm, Daniel Stenberg wrote:
> On Fri, 13 Jun 2003, Cris Bailiff wrote:
> > Hmm - I'm getting a segfault with the current CVS with 0.9.7a. Curious.
>
> Weird. I'm running this with 0.9.7a fine here. Have you tried doing a 'make
> clean' to get rid of old leftovers?

My build was from a fresh CVS checkout. It was a heisenbug (went away with
--enable-debug) but I finally tracked it down to a mangled stack - trivial
patch attached. I don't know if this fixes <0.9.7 as well...

> > Whilst I'm digging around in CVS, I noticed the addition of the
> > '--negotiate' and '--ntlm' flags for the new auth mechanisms. Looking at
> > the curlopt library code, it seems the intention is to 'choose one' when
> > making the request.
> >
> > I know this isn't a mature bit of code yet (paint still very wet), but
> > this seems a bit 'backwards' to me. The user would have to know/guess
> > beforehand which auth methods the server supports. I would have thought
> > it more 'natural' to have libcurl just choose from the list of methods
> > presented by the server. (You could still have flags to disable those you
> > don't like, for security purposes).
>
> I think you're absolutely right.
>
> We could have that option for forcing libcurl to use one particular
> authentication method, like if you know a certain page requires it (as it
> saves a round-trip). and we could have of the options be CURLAUTH_ANY and
> then libcurl would check what the remote site wants and use the most
> "suitable" in an order it decides (GSS-Negotiate => Digest => NTLM =>
> Basic, I guess).

The order seems about right. You can probably only save a round-trip for
Basic, and possibly NTLM, using this method (correct my if I'm wrong).

> The question is, what would the default be? Today, libcurl uses Basic if
> you use HTTP and set username+password. That means we basicly have
> CURLAUTH_BASIC set by default today.

Hmm, I see that curl just sends the Basic credentials on the first request, if
given a username/password, without waiting to see if the server actually
needs them or not.

Browsers don't usually do this - they wait until credentials are demanded, but
they have the benefit of being long-lived, so they can remember which content
needs a password after 1 extra round trip.

curl could be adding up to 50% more round-trips if it did this, as it
typically only does 1 request per run (though libcurl-using applications
wouldn't be as badly affected, I guess).

> I guess the only sensible thing that doesn't introduce weird side-effects
> to old users is to remain doing that as default, and allow a new option to
> set the ANY option.

Yeah, that seems reasonably cautious.

> I can't see any reason any user would decide to NOT use a specific
> authentication, if ANY is selected.
>
> Or am I wrong?

A user could well want to avoid using basic auth if the server doesn't offer
anything stronger - this prevents 'accidentally' offering the
username/password in effectively cleartext, which is vulnerable to sniffing
or a type of man-in-the-middle attack called a 'downgrade' attack. (A fake
server gets you to reveal your password by forcing the client to use only
Basic auth, defeating the point of the stronger methods.)

I'd say the 'ANY' flag should at least disable the sending of Basic in the
initial request, because if the server supports it, it probably wouldn't then
offer to negotiate anything stronger (like Digest or whatever), again
defeating the point of having them available.

Cheers,
Cris

-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5