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
Received on 2014-07-11