Secur32
Secur32.dll mainly contains the Secure Service Provider Interface, SSPI. SSPI allows developers to use different providers of secure socket-like services. In SSPI, a Secure Service Provider (SSP) is loaded by the system and queried for the capabilities it supports. You (the client developer) can choose which provider you want by name. Normal SSPs (I don't know a better name for them) are loaded by secur32.dll in the context of the calling process.
The are also authentication SSPs, which are capable of authenticating users. They're loaded (in Windows) in the context of the LSA. Since Wine doesn't have an LSA and doesn't authenticate users, I'm only talking about normal SSPs here.
SSPI is a plugin interface: SSPs are implemented in external DLLs, and secur32.dll loads them. Wine's secur32.dll is already able to load native SSP DLLs.
Wine's Secur32.dll also provides a couple of built-in SSPs, the NTLM provider and the Schannel provider.
Providers
NTLM
The NTLM provider is capable of authenticating against a Windows server, and encrypting/decrypting packets to and from that server. Wine's NTLM provider is being worked on by KaiBlin, and detailed in NtlmSigningAndSealing.
Native probably keeps NTLM in MSV1_0.DLL, which is an authentication SSP. There is no incentive for wine to put NTLM in a dll external to secur32.
SChannel
Schannel is Microsoft's implementation of SSL/TLS. SSL, the secure sockets layer, was designed to be a drop-in replacement for sockets: it performs authentication, and after authentication developers can write to and read from a "secure" socket as close to transparently as possible.
SSL was developed by Netscape. At some point they submitted it as an RFC to the IETF, and the IETF fixed some design flaws in it and renamed it Transport Layer Security, or TLS. The current version of the protocol is TLS 1.1, though that revision is very new, and most products only implement TLS 1.0. Both versions of TLS are very similar to each other and to SSL 3. SSL 2 has serious flaws and should not be used.
SChannel also supports PCT, which is a deprecated protocol by Microsoft that was replaced by SSL/TLS.
SChannel is also an authentication SSP, for the purpose of authenticating users using a client certificate (e.g., by a web server).
Kerberos
Starting at Windows 2000, kerberos 5 got integrated as kerberos.dll, which is yet another SSP/AP (Security Support Provider/Authentication Package). Kerberos is a robust IETF-approved authentication protocol, and Microsoft reused it as one of the underlying protocols for Active Directory.
Wine's secur32 does not support kerberos. However, it should not be a significant problem, as there are a few good free implementations of kerberos. The SingleSignOn page should capture this information better.
Negotiate
Negotiate is the Microsoft name for SPNEGO, which is a protocol for negotiating other security protocols, such as ntlm and kerberos. It is mostly known when authenticating to NTLM-requiring HTTP servers or proxies. RFC 4178 and RFC 4559 are a good start.
Uses
- rpcrt4 uses the NTLM provider for encrypted RPC
Google Talk uses the Schannel provider for TLS (see bug 3254)
FolderShare apparently uses the Schannel provider too (see bug 4538)
- wininet should use SSPI for https instead of using openssl directly.
- wininet should use SSPI for http authentication. Doing so might allow IE to authenticate against NTLM-requiring servers using built-in DLLs.
TODO
Wine's secur32.dll only has stubs for schannel. I want to create a test client and server that passes data back and forth through memory buffers. The server requires a certificate with a private key in it. This makes sense, otherwise it can't provide an identity to the client. The format it wants it in depends on certificate stores in Crypt32, which I think is finally up to the task.
Ideally the built-in schannel implementation would use CryptoAPI for its crypto functions, and only load OpenSSL for the SSL/TLS functions that aren't crypto-related. Doing so would require using the ENGINE interface available since OpenSSL version 0.9.7. Using OpenSSL is a bit of a challenge, though, since:
- We can't statically link it because the license isn't LGPL-compatible.
- Dynamically linking it exposes us to conflicts between versions (and OpenSSL doesn't provide guarantees of binary compatibility.)
GnuTLS also doesn't allow us to provide our own crypto, although since it's LGPL we might be able to import some of its source and massage it to use CryptoAPI rather than its own crypto routines.
We may also find that implementing SSL/TLS ourselves is more expedient than importing someone else's source, simply because the interface required by SSPI is so unique (and also because large portions of what SSL libraries provide are already implemented in crypt32 and rsaenh.)