Top Qs
Timeline
Chat
Perspective

Comparison of TLS implementations

From Wikipedia, the free encyclopedia

Remove ads

The Transport Layer Security (TLS) protocol provides the ability to secure communications across or inside 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.

Remove ads

Overview

More information Implementation, Developed by ...
  1. Apache-2.0 for OpenSSL 3.0 and later releases. OpenSSL-SSLeay dual-license for any release before OpenSSL 3.0.
Remove ads

TLS/SSL protocol version support

Summarize
Perspective

Several versions of the TLS protocol exist. SSL 2.0 is a deprecated[27] 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.[28] 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.[29] 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.[30] 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.[31]

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).[32]

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.[33]

TLS 1.3 (2018) specified in RFC 8446 includes major optimizations and security improvements. QUIC (2021) specified in RFC 9000 and DTLS 1.3 (2022) specified in RFC 9147 builds on TLS 1.3. The publishing of TLS 1.3 and DTLS 1.3 obsoleted TLS 1.2 and DTLS 1.2.

Note that there are known vulnerabilities in SSL 2.0 and SSL 3.0. In 2021, IETF published RFC 8996 also forbidding negotiation of TLS 1.0, TLS 1.1, and DTLS 1.0 due to known vulnerabilities. NIST SP 800-52 requires support of TLS 1.3 by January 2024. Support of TLS 1.3 means that two compliant nodes will never negotiate TLS 1.2.

More information Implementation, SSL 2.0 (insecure) ...
  1. As of SSL-J 7.0, support for TLS 1.0 and 1.1 has been removed
  2. SSL 2.0 client hello is supported for backward compatibility reasons even though SSL 2.0 is not supported.
  3. Server-side implementation of the SSL/TLS protocol still supports processing of received v2-compatible client hello messages."NSS 3.24 release notes". Mozilla Developer Network. Mozilla. Archived from the original on 2016-08-26. Retrieved 2016-06-19.
  4. Secure Transport: SSL 2.0 was discontinued in OS X 10.8. SSL 3.0 was discontinued in OS X 10.11 and iOS 9.TLS 1.1, 1.2 and DTLS are available on iOS 5.0 and later, and OS X 10.9 and later."Technical Note TN2287: iOS 5 and TLS 1.2 Interoperability Issues". iOS Developer Library. Apple Inc. Retrieved 2012-05-03.
  5. Since OTP 22
  6. Since OTP 23
Remove ads

NSA Suite B Cryptography

Summarize
Perspective

Required components for NSA Suite B Cryptography (RFC 6460) are:

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.

More information Implementation, TLS 1.2 Suite B ...

Certifications

Summarize
Perspective

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

More information Implementation, FIPS 140-3 ...
  1. with Sun Sparc 5 w/ Sun Solaris v 2.4SE (ITSEC-rated)
  2. with Sun Ultra-5 w/ Sun Trusted Solaris version 2.5.1 (ITSEC-rated)
  3. with Solaris v8.0 with AdminSuite 3.0.1 as specified in UK IT SEC CC Report No. P148 EAL4 on a SUN SPARC Ultra-1
  4. with these platforms; Red Hat Enterprise Linux Version 4 Update 1 AS on IBM xSeries 336 with Intel Xeon CPU, Trusted Solaris 8 4/01 on Sun Blade 2500 Workstation with UltraSPARC IIIi CPU
  5. with these platforms; Red Hat Enterprise Linux v5 running on an IBM System x3550, Red Hat Enterprise Linux v5 running on an HP ProLiant DL145, Sun Solaris 10 5/08 running on a Sun SunBlade 2000 workstation, Sun Solaris 10 5/08 running on a Sun W2100z workstation
Remove ads

Key exchange algorithms (certificate-only)

Summarize
Perspective

This section lists the certificate verification functionality available in the various implementations.

More information Implementation, RSA ...
Remove ads

Key exchange algorithms (alternative key-exchanges)

More information Implementation, SRP ...
Remove ads

Certificate verification methods

More information Implementation, Application-defined ...
Remove ads

Encryption algorithms

More information Implementation, Block cipher with mode of operation ...
Notes
  1. This algorithm is not defined yet as TLS cipher suites in RFCs, is proposed in drafts.
  2. authentication only, no encryption
  3. This algorithm is implemented in an NSS fork used by Pale Moon.

Obsolete algorithms

More information Implementation, Block cipher with mode of operation ...
Notes
  1. IDEA and DES have been removed from TLS 1.2.[152]
  2. 40 bits strength of cipher suites were designed to operate at reduced key lengths in order to comply with US regulations about the export of cryptographic software containing certain strong encryption algorithms (see Export of cryptography from the United States). These weak suites are forbidden in TLS 1.1 and later.
  3. The RC4 attacks weaken or break RC4 used in SSL/TLS. Use of RC4 is prohibited by RFC 7465.
  4. The RC4 attacks weaken or break RC4 used in SSL/TLS.
Remove ads

Supported elliptic curves

Summarize
Perspective

This section lists the supported elliptic curves by each implementation.

Defined curves in RFC 8446 (for TLS 1.3) and RFC 8422, 7027 (for TLS 1.2 and earlier)

More information applicable TLS version, TLS 1.3 and earlier ...

Deprecated curves in RFC 8422

More information Implementation, sect163k1NIST K-163 (1) ...
More information Implementation, secp160k1 (15) ...
Notes
  1. These elliptic curves were "Disabled by Default" in current JDK families as part of JDK-8236730.[183]
  2. These elliptic curves were subsequently removed in JDK 16+ as part of JDK-8252601.[184]
Remove ads

Data integrity

More information Implementation, HMAC-MD5 ...
Remove ads

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.

More information Implementation, DEFLATE (insecure) ...

Extensions

Summarize
Perspective

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

More information Implementation, Secure Renegotiation ...

Assisted cryptography

Summarize
Perspective

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.

More information Implementation, PKCS #11 device ...
  1. Pure Java implementations relies on JVM processor optimization capabilities, such as OpenJDK support for AES-NI[228]
  2. BSAFE SSL-J can be configured to run in native mode, using BSAFE Crypto-C Micro Edition to benefit from processor optimization.[229]

System-specific backends

Summarize
Perspective

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.

More information Implementation, /dev/crypto ...

Cryptographic module/token support

More information Implementation, TPM support ...

Code dependencies

More information Implementation, Dependencies ...

Development environment

Summarize
Perspective
More information Implementation, Namespace ...
  1. ^
    ASN.1 manipulation classes
  2. ^
    Cert-J proprietary API
  3. ^
    Certificate Path manipulation classes
  4. ^
    Crypto-J proprietary API, JCE, CMS and PKI
  5. API
  6. ^
    SSLJ proprietary API
  7. ^
    JSSE API

Portability concerns

More information Implementation, Platform requirements ...

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

Loading related searches...

Wikiwand - on

Seamless Wikipedia browsing. On steroids.

Remove ads