[2] = Requires iOS 5.0 or later, or OS X 10.8.0 or later
[3] = Requires Windows Vista or later
[4] = Requires Windows 7 or later
[5] = Requires IBM i 7.1 TR6 or later
[6] = The same feature set is also provided by LibreSSL and BoringSSL.
[7] = support for ALPN and NPN was added in Windows 8.1 / Server 2012 R2.
[8] = Via external engine_pkcs11;
SUBTITLE(Glossary of Terms)
Native name Check: If yes, then this means that the engine will
automatically check the domain name in the server's certificate against the
domain name used to connect to the server, unless CURLOPT_VERIFYHOST was
manually disabled. If no, then libcurl will perform this check manually.
CRL: CRL means "Certificate Revocation List" and is used to check to
see if any certificates in the server's chain have been revoked for some
reason. If automatic, then the engine will automatically download a CRL and
use it to evaluate the trust of the server's certificate chain when performing
the TLS handshake. If manual, then the engine will not automatically use a
CRL, but you can provide one that has been downloaded separately by using the
CURLOPT_CRL option. If no, then the CURLOPT_CRL option will be ignored.
SSLv2: This was the first public release of the SSL protocol. It is
deprecated and really should no longer be used, because it has a number of
serious security problems. Even if your engine supports it, libcurl will never
default to allowing SSLv2 when performing a TLS handshake. Support for SSLv2
is only provided here if you need to connect to a very old (circa 1995) SSL
server that does not support a newer version of the protocol.
SSLv3: This version of SSL fixed all of the major weaknesses in
SSLv2. It is still widely supported on the public Internet, mainly because
Microsoft Internet Explorer 6 does not support TLS by default, although TLS is
a preferred protocol.
TLSv1.0: TLS is a slight variation on SSLv3 that was the first version
of the protocol to be approved of by the Internet Engineering Task Force
(IETF). This version of TLS has been available since 1999 and is by far the
most widely supported version on the public Internet. There have been a few
minor security vulnerabilities found in TLSv1.0 which were fixed later, but
all of them (so far) have been easily worked around, which has contributed to
the longevity of this version of TLS.
TLSv1.1: TLSv1.1 is similar to v1.0, except that it has a better fix
for the CBC (Cipher Block Chain) cipher-suite attack that lead to the BEAST
(Browser Exploit Against SSL/TLS) vulnerability in TLSv1.0. Unfortunately it
was released seven years after v1.0, and took even longer to start appearing
in TLS engines, so it's not very widely supported by servers yet.
TLSv1.2: TLSv1.2 provides even better security than TLSv1.1 and
earlier, with support for many all-new cipher suites that are even more
difficult to crack. Unfortunately TLSv1.2 is not widely used on the public
Internet yet for the same reasons that v1.1 support is scarce.
TLS SRP: SRP means "Secure Remote Password" and it is a method of
performing client-side authentication with a TLS server by using a user name
and password, sometimes coupled with a certificate. It is not yet widely
supported, but for the engines that do support it, you can provide the
credentials to curl by using the CURLOPT_TLSAUTH_USERNAME and
CURLOPT_TLSAUTH_PASSWORD options.
TLS ECC: ECC means "Elliptic Curve Cryptography" and it is an advanced
set of cipher-suites that are used in TLS connections (typically with
TLSv1.2). Not all engines support ECC.
Uses Certificate/Key Files: Some engines, such as OpenSSL, read
certificates and keys from files rather than a central database. These engines
require you to use a certificate bundle in order to verify a server's
certificate chain; this is usually set at build time but can also be set by
using the CURLOPT_CAINFO option.
Uses Certificate/Key Database: Some engines, such as Apple's Security
framework, use a central database instead of separate files to store
certificates and keys. Apple's Security framework database, for instance, is
called the Keychain. For engines that use a database and don't also support
files, the CURLOPT_CAINFO option is ignored.
Crypto module/token support: Support for cryptographic hardware tokens
and software databases is typically provided via
; PKCS#11 on POSIX platforms,
and via platform-specific APIs on Windows and Darwin. Examples of PKCS#11
software tokens include the GNOME keyring, and the NSS "soft token" database.
Integrates with system token database: Platforms often have a
system-wide configuration which specifies which crypto modules/token should
be visible in which applications. Many Linux distributions have chosen
to use p11-kit;
to provide this configuration, and some now consider it a bug for
applications not to automatically use the tokens configured therein.
Select Certificates/Keys with PKCS#11 URI:RFC 7512 defines a
standard URI format for specifying objects within PKCS#11
tokens/databases.
FIPS-140: FIPS-140 is a security standard used by the United States and
Canada for transferring information that is sensitive but not classified. If
yes, and you are using curl or a libcurl-based application in the US or
Canadian government, or in a government contractor, then it's okay for you to
use the engine when building curl/libcurl.
License: If you are deploying an application that uses libcurl, then
the license used by the engine may affect whether or not you are able to
distribute your application legally. OpenSSL's 4-clause BSD license, for
instance, is not compatible with the GNU GPL.
SUBTITLE(More reading)