Comparison of TLS implementations
The Transport Layer Security (TLS) protocol provides the ability to secure communications across networks. This comparison of TLS implementations compares several of the most notable libraries. There are several TLS implementations which are free software and open source.

All comparison categories use the stable version of each implementation listed in the overview section. The comparison is limited to features that directly relate to the TLS protocol.

Overview

Protocol support 
Several versions of the TLS protocol exist. SSL 2.0 is a deprecated protocol version with significant weaknesses.  SSL 3.0 (1996) and TLS 1.0 (1999) are successors with two weaknesses in CBC-padding that were explained in 2001 by Serge Vaudenay.  TLS 1.1 (2006) fixed only one of the problems, by switching to random initialization vectors (IV) for CBC block ciphers, whereas the more problematic use of mac-pad-encrypt instead of the secure pad-mac-encrypt was addressed with RFC 7366.  A workaround for SSL 3.0 and TLS 1.0, roughly equivalent to random IVs from TLS 1.1, was widely adopted by many implementations in late 2011, so from a security perspective, all existing version of TLS 1.0, 1.1 and 1.2 provide equivalent strength in the base protocol and are suitable for 128-bit security according to NIST SP800-57 up to at least 2030.  In 2014, the POODLE vulnerability of SSL 3.0 was discovered, which takes advantage of the known vulnerabilities in CBC, and an insecure fallback negotiation used in browsers.

TLS 1.2 (2008) introduced a means to identify the hash used for digital signatures.  While permitting the use of stronger hash functions for digital signatures in the future (rsa,sha256/sha384/sha512) over the SSL 3.0 conservative choice (rsa,sha1+md5), the TLS 1.2 protocol change inadvertently and substantially weakened the default digital signatures and provides (rsa,sha1) and even (rsa,md5).

Datagram Transport Layer Security (DTLS or Datagram TLS) 1.0 is a modification of TLS 1.1 for a packet-oriented transport layer, where packet loss and packet reordering have to be tolerated.  The revision DTLS 1.2 based on TLS 1.2 was published in January 2012.

Note that there are known vulnerabilities in SSL 2.0 and SSL 3.0.  With the exception of the predictable IVs (for which an easy workaround exists) all currently known vulnerabilities affect all version of TLS 1.0/1.1/1.2 alike.

NSA Suite B Cryptography 
Required components for NSA Suite B Cryptography (RFC 6460) are:
 Advanced Encryption Standard (AES) with key sizes of 128 and 256 bits. For traffic flow, AES should be used with either the Counter Mode (CTR) for low bandwidth traffic or the Galois/Counter Mode (GCM) mode of operation for high bandwidth traffic (see Block cipher modes of operation) — symmetric encryption
 Elliptic Curve Digital Signature Algorithm (ECDSA) — digital signatures
 Elliptic Curve Diffie–Hellman  (ECDH) — key agreement
 Secure Hash Algorithm 2 (SHA-256 and SHA-384) — message digest

Per CNSSP-15, the 256-bit elliptic curve (specified in FIPS 186-2), SHA-256, and AES with 128-bit keys are sufficient for protecting classified information up to the Secret level, while the 384-bit elliptic curve (specified in FIPS 186-2), SHA-384, and AES with 256-bit keys are necessary for the protection of Top Secret information.

Certifications 
Note that certain certifications have received serious negative criticism from people who are actually involved in them.

Key exchange algorithms (certificate-only) 
This section lists the certificate verification functionality available in the various implementations.

Key exchange algorithms (alternative key-exchanges)

Certificate verification methods

Encryption algorithms 

 Notes

Obsolete algorithms 

 Notes

Supported elliptic curves 
This section lists the supported elliptic curves by each implementation.

 Notes

Data integrity

Compression 
Note the CRIME security exploit takes advantage of TLS compression, so conservative implementations do not enable compression at the TLS level. HTTP compression is unrelated and unaffected by this exploit, but is exploited by the related BREACH attack.

Extensions 
In this section the extensions each implementation supports are listed. Note that the Secure Renegotiation extension is critical for HTTPS client security . TLS clients not implementing it are vulnerable to attacks, irrespective of whether the client implements TLS renegotiation.

Assisted cryptography 
This section lists the known ability of an implementation to take advantage of CPU instruction sets that optimize encryption, or utilize system specific devices that allow access to underlying cryptographic hardware for acceleration or for data separation.

System-specific backends 
This section lists the ability of an implementation to take advantage of the available operating system specific backends, or even the backends provided by another implementation.

Cryptographic module/token support

Code dependencies

Development environment 

 API

Portability concerns

See also
 SCTP — with DTLS support
 DCCP — with DTLS support
 SRTP — with DTLS support (DTLS-SRTP) and Secure Real-Time Transport Control Protocol (SRTCP)

References 

Cryptographic software
TLS implementations