Re: [PATCH] SF bug #1302: HTTP Auth Negotiate sends Kerberos token instead of SPNEGO token
Date: Fri, 11 Jul 2014 12:18:02 +0100
On Fri, 2014-07-11 at 12:21 +0200, Michael Osipov wrote:
> Your patch looks good but not complete, right?
Right. If you look at the top of my tree at
http://git.infradead.org/users/dwmw2/curl.git you'll see it's somewhat
more complete now — on a system with sane GSSAPI I can watch it
authenticate correctly using SPNEGO. Against one server I see it trying
IAKERB and then correctly falling back to GSSNTLMSSP, for example. And
against another I can either watch it work correctly with Kerberos, or
if I run 'kdestroy' then I can see it use GSSNTLMSSP instead. Everything
(To answer an earlier question that's the implementation at
https://fedorahosted.org/gss-ntlmssp/ not the Heimdal one, btw).
The reason I have GSSAPI in my head this week is because I've recently
added GSSAPI proxy support to the OpenConnect VPN client. As part of
that, I tested on FreeBSD, OpenBSD, NetBSD, OSX and Solaris 11 (as well
as Windows). So I'm fairly happy with the portability on sane platforms.
However, I appreciate that libcurl needs to be a little more concerned
about portability than OpenConnect, so we need a strategy for coping
with ancient GSSAPI implementations that don't do SPNEGO.
One possibility is for Curl_gss_init_sec_context() to try again with the
default mechanism if the invocation with &gss_spnego_mech fails. And
then I think we'd just put the Kerberos token on the wire instead of
screwing around and playing at SPNEGO. Most servers will tolerate that
(which is why nobody's really been complaining about curl's existing
> I would like to follow
> your improvements, make comments what can done even better. What I had
> in mind additionally to have '--kerberos' react on 'WWW-Authenticate:
> Kerberos' too.
Is that really seen in the wild? It shouldn't be hard to support,
> More over, I can test the entire stuff on three Unix OSes against
> GSS-API, SSPI, and JGSS. So, a very good test coverage should be
> achieved. Servers on FreeBSD, Windows Servers, HP-UX and HTTP proxy on
> Windows Server.
Great. I've only been testing with Dante for SOCKS, and squid for HTTP.
The latter supports NTLM as well as Negotiate/SPNEGO using either
Kerberos or NTLMSSP methods, all of which are working fine.
I would be *very* grateful if you could manage to test OpenConnect in
your environment too, please. It's available either from
./openconnect -v -v --dump-http-traffic --proxy proxy.comain.com:port www.facebook.com
Obviously if it actually gets to the point of trying to make a VPN
connection to www.facebook.com it's not going to succeed. But if it gets
that far then the *proxy* part has worked ... :)
- application/x-pkcs7-signature attachment: smime.p7s