cURL / Mailing Lists / curl-library / Single Mail


Re: Windows SSPI Schannel implementation ready

From: Yang Tse <>
Date: Tue, 12 Jun 2012 21:29:59 +0200

Marc Hoersken <> wrote:

> I do understand and support Yang's arguments, but I also understand
> that we need to figure out a good way to illustrate the features
> provided by SSPI or any other security provider.

The fact that security.dll or secur32.dll is being used is exposed for
historical reasons as libcurl's 'SSPI' feature. Exposing capabilities
in a finer grained way would imply exposing other 'feature' literals.
for example 'SSO' could represent single-sign-on capability, which
could equally be achieved even without SSPI if for example the NTLM_WB
works as intended.

Additionally not all capabilities of each libcurl flavour expose everything.

Steve Holme <> wrote:

> There are two reasons for including Windows SSPI in the version information.
> 1) curl displays the SSL library in its version string and as such should
> display something when SSL through Windows SSPI is enabled.

Should? Why? What does it provide besides completeness?

SSL support is indicated by 'https', 'ftps', etc in the supported
protocols list, and that SSPI is in use in the features list.

> 2) Windows SSPI can be thought of as the equivalent to OpenSSL or better
> still GNUTLS as it is a provider of security related features and provides
> libcurl with the following:

I still find no need to expose it in this new way which has been introduced.

> From discussion with Daniel, and to a certain degree from your email of 23
> April, I believe that the feature of SSPI as listed in curl's feature string
> actually represents the SSO capability of Windows SSPI and not everything
> that Windows SSPI provides (or at least it shouldn't represent all of SSPI
> as otherwise you wouldn't display GSS-Negotiate and NTLM for example).

Ah, forget that mail of mine, I wrote it out of memory. The fact is
that SSPI feature actually represents that security.dll or secur32.dll
is in use. Very long-long time ago it represented SSO but that was
changed also long time ago to what it represents currently.

> WinSSPI is a short friendly name, or package name if you like, for
> security.dll / secur32.dll just as OpenSSL is the package name for
> libssl32.dll and libeay32.dll. Originally, Mark had this as SChannel which
> we decided wasn't a good name.

I also find it a good name, but no need to use it.

SSPI might use schannel.dll, ntlmssp.dll, kerberos.dll, cryptdll.dll
and any other that gets properly injected into the system. Should we
also show the version of those libs?

>> The user/developer has very  little choice relative
>> to which version is used.
> This is very true... and I guess it would be similar to something like
> OpenSSL being pre-installed as part of Solaris for example ;-)

Even on Solaris a user might build on its own a different OpenSSL
version and use it, thing which is absolutely impossible on Windows
for security.dll, secur32.dll and all MS system libs. So my question
remains why do we need to expose MS system lib version?

> My own preference is to keep it because 1) It is in keeping with other
> security providers in curl, 2) Like any of the version / package information
> it is useful to know and 3) We need to display something in the SSL version
> string so if we were to ditch it what would we display here?

Well, its clear we have different opinions on this.

List admin:
Received on 2012-06-12