Am 2014-07-11 13:18, schrieb David Woodhouse:
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
works nicely.
(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
Negotiate support).
I would implement a fallback but provide two options where one should be
picked sticked to it:
1. Discover SPNEGO capability at compile time with autoconf. GSS-API
provides this option:
OM_uint32 major, minor;
gss_OID_set mech_set;
major = gss_indicate_mechs(&minor, &mech_set);
and then you can test the for set members with a default function.
2. Use SPNEGO by default and if the GSS-API impl does not support SPNEGO
it will fail with an GSS error.
Give that this is a corner case and should apply only to a fraction of
users, I would go for option 2, e.g., your implementation.
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,
certainly.
Yes, Microsoft Forefront TMG offers that.
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
git://git.infradead.org/users/dwmw2/openconnect.git or
ftp://ftp.infradead.org/pub/openconnect/openconnect-6.00.tar.gz
./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 ... :)
I need access to that code via HTTP. Nothing else works at work but I
would be happy to try that. Results won't be available before next friday.
Michael
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
