Community hub
0 subscribers7 pages, 0 posts
Recent from talks
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Comparison of TLS implementations.
Nothing was collected or created yet.
Comparison of TLS implementations
View on Wikipediafrom Wikipedia
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.
Overview
[edit]| Implementation | Developed by | Open source | Software license | Copyright holder | Written in | Latest stable version, release date | Origin | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Botan | Jack Lloyd | Yes | Simplified BSD License | Jack Lloyd | C++ | 3.10.0 (November 6, 2025[1]) [±] | US (Vermont) | ||||||||||
| BoringSSL | Yes | OpenSSL-SSLeay dual-license, ISC license | Eric Young, Tim Hudson, Sun, OpenSSL project, Google, and others | C, C++, Go, assembly | No stable releases[2] | Australia/EU[citation needed] | |||||||||||
| Bouncy Castle | The Legion of the Bouncy Castle Inc. | Yes | MIT License | Legion of the Bouncy Castle Inc. | Java, C# |
|
Australia | ||||||||||
| BSAFE | Dell, formerly RSA Security | No | Proprietary | Dell | Java, C, assembly | SSL-J 7.4 (December 2, 2025[8]) [±] |
Australia | ||||||||||
| cryptlib | Peter Gutmann | Yes | Sleepycat License and commercial license | Peter Gutmann | C | 3.4.8 (April 30, 2025[10]) [±] | NZ | ||||||||||
| GnuTLS | GnuTLS project | Yes | LGPL-2.1-or-later | Free Software Foundation | C | 3.8.11[11]  2025-11-20
|
EU (Greece and Sweden) | ||||||||||
| Java Secure Socket Extension (JSSE) | Oracle | Yes | GNU GPLv2 and commercial license | Oracle | Java |
25 LTS (September 16, 2025[12]) [±] |
US | ||||||||||
| LibreSSL | OpenBSD Project | Yes | Apache-1.0, BSD-4-Clause, ISC, and public domain | Eric Young, Tim Hudson, Sun, OpenSSL project, OpenBSD Project, and others | C, assembly | 4.2.1[17] 2025-10-31
|
Canada | ||||||||||
| MatrixSSL[18] | PeerSec Networks | Yes | GNU GPLv2+ and commercial license | PeerSec Networks | C | 4.2.2 (September 11, 2019 [19]) [±] | US | ||||||||||
| Mbed TLS (previously PolarSSL) | Arm | Yes | Apache License 2.0, GNU GPLv2+ and commercial license | Arm Holdings | C | 4.0.0[20] (15 October 2025) [±]
|
EU (Netherlands) | ||||||||||
| Network Security Services (NSS) | Mozilla, AOL, Red Hat, Sun, Oracle, Google and others | Yes | MPL 2.0 | NSS contributors | C, assembly |
|
US | ||||||||||
| OpenSSL | OpenSSL project | Yes | Apache-2.0[a] | Eric Young, Tim Hudson, Sun, OpenSSL project, and others | C, assembly | 3.6.1[22] 2026-01-27
|
Australia/EU | ||||||||||
| Rustls | Joe Birr-Pixton, Dirkjan Ochtman, Daniel McCarney, Josh Aas, and open source contributors | Yes | Apache-2.0, MIT License and ISC | Open source contributors | Rust | v0.23.31 (July 29, 2025[23]) [±] | United Kingdom | ||||||||||
| s2n | Amazon | Yes | Apache License 2.0, GNU GPLv2+ and commercial license | Amazon.com, Inc. | C | Continuous | US | ||||||||||
| Schannel | Microsoft | No | Proprietary | Microsoft Corporation | Windows 11, 2021-10-05 | US | |||||||||||
| Secure Transport | Apple Inc. | Yes | APSL 2.0 | Apple Inc. | 57337.20.44 (OS X 10.11.2), 2015-12-08 | US | |||||||||||
| wolfSSL (previously CyaSSL) | wolfSSL[24] | Yes | GNU GPLv3+ and commercial license | wolfSSL Inc.[25] | C, assembly | 5.8.4 (November 20, 2025[26]) [±] | US | ||||||||||
| Erlang/OTP SSL application | Ericsson | Yes | Apache License 2.0 | Ericsson | Erlang | OTP-21, 2018-06-19 | Sweden | ||||||||||
| Implementation | Developed by | Open source | Software license | Copyright owner | Written in | Latest stable version, release date | Origin |
- ^ Apache-2.0 for OpenSSL 3.0 and later releases. OpenSSL-SSLeay dual-license for any release before OpenSSL 3.0.
TLS/SSL protocol version support
[edit]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.
| Implementation | SSL 2.0 (insecure)[34] | SSL 3.0 (insecure)[35] | TLS 1.0 (deprecated)[36] | TLS 1.1 (deprecated)[37] | TLS 1.2[38] | TLS 1.3 | DTLS 1.0 (deprecated)[39] | DTLS 1.2[33] | DTLS 1.3 |
|---|---|---|---|---|---|---|---|---|---|
| Botan | No | No[40] | No | No | Yes | Yes | No | Yes | No |
| BoringSSL | Yes | Yes | Yes | Yes | Yes | Yes | No | ||
| Bouncy Castle | No | No | Yes | Yes | Yes | Yes | Yes | Yes | No |
| BSAFE SSL-J[41] | No | Disabled by default | No[a] | No[a] | Yes | Yes | No | No | No |
| cryptlib | No | No | Yes | Yes | Yes | Yes | No | No | No |
| GnuTLS | No[b] | Disabled by default[42] | Yes | Yes | Yes | Yes[43] | Yes | Yes | No |
| JSSE | No[b] | Disabled by default[44] | Disabled by default[45] | Disabled by default[45] | Yes | Yes | Yes | Yes | No |
| LibreSSL | No[46] | No[47] | Yes | Yes | Yes | Yes | Yes | Yes[48] | No |
| MatrixSSL | No | Disabled by default at compile time[49] | Yes | Yes | Yes | Yes | Yes | Yes | No |
| Mbed TLS | No | No[50] | No[50] | No[50] | Yes | Yes (experimental) |
Yes[51] | Yes[51] | No |
| NSS | No[c] | Disabled by default[52] | Yes | Yes[53] | Yes[54] | Yes[55] | Yes[53] | Yes[56] | No |
| OpenSSL | No[57] | Disabled by default | Yes | Yes[58] | Yes[58] | Yes | Yes | Yes[59] | No |
| Rustls | No[60] | No[60] | No[60] | No[60] | Yes[60] | Yes[60] | No | No | No |
| s2n[61] | No | Disabled by default | Yes | Yes | Yes | Yes | No | No | No |
| Schannel XP, 2003[62] | Disabled by default in MSIE 7 | Enabled by default | Enabled by default in MSIE 7 | No | No | No | No | No | No |
| Schannel Vista[63] | Disabled by default | Enabled by default | Yes | No | No | No | No | No | No |
| Schannel 2008[63] | Disabled by default | Enabled by default | Yes | Disabled by default (KB4019276) | Disabled by default (KB4019276) | No | No | No | No |
| Schannel 7, 2008R2[64] | Disabled by default | Disabled by default in MSIE 11 | Yes | Enabled by default in MSIE 11 | Enabled by default in MSIE 11 | No | Yes[65] | No[65] | No |
| Schannel 8, 2012[64] | Disabled by default | Enabled by default | Yes | Disabled by default | Disabled by default | No | Yes | No | No |
| Schannel 8.1, 2012R2, 10 RTM & v1511[64] | Disabled by default | Disabled by default in MSIE 11 | Yes | Yes | Yes | No | Yes | No | No |
| Schannel 10 v1607 / 2016[66] | No | Disabled by default | Yes | Yes | Yes | No | Yes | Yes | No |
| Schannel 11 / 2022[67] | No | Disabled by default | Yes | Yes | Yes | Yes | Yes | Yes | No |
| Secure Transport
OS X 10.2–10.7, iOS 1–4 |
Yes | Yes | Yes | No | No | No | No | No | |
| Secure Transport OS X 10.8–10.10, iOS 5–8 | No[d] | Yes | Yes | Yes[d] | Yes[d] | Yes[d] | No | No | |
| Secure Transport OS X 10.11, iOS 9 | No | No[d] | Yes | Yes | Yes | Yes | Unknown | No | |
| Secure Transport OS X 10.13, iOS 11 | No | No[d] | Yes | Yes | Yes | Yes (draft version)[68] |
Yes | Unknown | No |
| wolfSSL | No | Disabled by default[69] | Disabled by default[70] | Yes | Yes | Yes | Yes | Yes | Yes |
| Erlang/OTP SSL application[71] | No [e] | No [f] | Disabled by default [e] | Disabled by default [e] | Yes | Partially [g] | Disabled by default [e] | Yes | No |
| Implementation | SSL 2.0 (insecure)[34] | SSL 3.0 (insecure)[35] | TLS 1.0 (deprecated)[36] | TLS 1.1 (deprecated)[37] | TLS 1.2[38] | TLS 1.3 | DTLS 1.0 (deprecated)[39] | DTLS 1.2[33] | DTLS 1.3 |
- ^ a b As of SSL-J 7.0, support for TLS 1.0 and 1.1 has been removed
- ^ a b SSL 2.0 client hello is supported for backward compatibility reasons even though SSL 2.0 is not supported.
- ^ 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.
- ^ a b c d e f 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.
- ^ a b c d Since OTP 22
- ^ Since OTP 23
- ^ "Erlang OTP SSL application TLS 1.3 compliance table".
NSA Suite B Cryptography
[edit]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.
| Implementation | TLS 1.2 Suite B |
|---|---|
| Botan | Yes |
| Bouncy Castle | Yes |
| BSAFE | Yes[41] |
| cryptlib | Yes |
| GnuTLS | Yes |
| JSSE | Yes[72] |
| LibreSSL | Yes |
| MatrixSSL | Yes |
| Mbed TLS | Yes |
| NSS | No[73] |
| OpenSSL | Yes[59] |
| Rustls | Yes[60] |
| S2n | |
| Schannel | Yes[74] |
| Secure Transport | No |
| wolfSSL | Yes |
| Implementation | TLS 1.2 Suite B |
Certifications
[edit]Note that certain certifications have received serious negative criticism from people who are actually involved in them.[75]
| Implementation | FIPS 140-1, FIPS 140-2[76] | FIPS 140-3 | |
|---|---|---|---|
| Level 1 | Level 2[disputed – discuss] | Level 1 | |
| Botan[77] | |||
| Bouncy Castle | BC-FJA 2.0.0 (#4743) BC-FJA 2.1.0 (#4943) BC-FNA 1.0.2 (#4416 |
||
| BSAFE SSL-J[78] | Crypto-J 6.0 (1785, 1786) Crypto-J 6.1 / 6.1.1.0.1 (2057, 2058) Crypto-J 6.2 / 6.2.1.1 (2468, 2469) Crypto-J 6.2.4 (3172, 3184) Crypto-J 6.2.5 (#3819, #3820) Crypto-J 6.3 (#4696, #4697) |
Crypto-J 7.0 (4892) | |
| cryptlib[79] | |||
| GnuTLS[80] | Red Hat Enterprise Linux GnuTLS Cryptographic Module (#2780) | ||
| JSSE | |||
| LibreSSL[46] | no support | ||
| MatrixSSL[81] | SafeZone FIPS Cryptographic Module: 1.1 (#2389) | ||
| Mbed TLS[82] | |||
| NSS[83] | Network Security Services: 3.2.2 (#247) Network Security Services Cryptographic Module: 3.11.4 (#815), 3.12.4 (#1278), 3.12.9.1 (#1837) |
Netscape Security Module: 1 (#7[notes 1]), 1.01 (#47[notes 2]) Network Security Services: 3.2.2 (#248[notes 3]) Network Security Services Cryptographic Module: 3.11.4 (#814[notes 4]), 3.12.4 (#1279, #1280[notes 5]) |
|
| OpenSSL[84] | OpenSSL FIPS Object Module: 1.0 (#624), 1.1.1 (#733), 1.1.2 (#918), 1.2, 1.2.1, 1.2.2, 1.2.3 or 1.2.4 (#1051) 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6, 2.0.7 or 2.0.8 (#1747) |
||
| Rustls | aws-lc FIPS module[85] (#4759) | ||
| Schannel[86] | Cryptographic modules in Windows NT 4.0, 95, 95, 2000, XP, Server 2003, CE 5, CE 6, Mobile 6.x, Vista, Server 2008, 7, Server 2008 R2, 8, Server 2012, RT, Surface, Phone 8 See details on Microsoft FIPS 140 Validated Cryptographic Modules |
||
| Secure Transport | Apple FIPS Cryptographic Module: 1.0 (OS X 10.6, #1514), 1.1 (OS X 10.7, #1701) Apple OS X CoreCrypto Module; CoreCrypto Kernel Module: 3.0 (OS X 10.8, #1964, #1956), 4.0 (OS X 10.9, #2015, #2016) Apple iOS CoreCrypto Module; CoreCrypto Kernel Module: 3.0 (iOS 6, #1963, #1944), 4.0 (iOS 7, #2020, #2021) |
||
| wolfSSL[87] | wolfCrypt FIPS Module: 4.0 (#3389) See details on NIST certificate for validated Operating Environments wolfCrypt FIPS Module: 3.6.0 (#2425) See details on NIST certificate for validated Operating Environments |
wolfCrypt FIPS Module (#4178) See details on NIST certificate | |
| Implementation | Level 1 | Level 2 | Level 1 |
| FIPS 140-1, FIPS 140-2 | FIPS 140-3 | ||
- ^ with Sun SPARC 5 w/ Sun Solaris v 2.4SE (ITSEC-rated)
- ^ with Sun Ultra-5 w/ Sun Trusted Solaris version 2.5.1 (ITSEC-rated)
- ^ 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
- ^ 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
- ^ 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
Key exchange algorithms (certificate-only)
[edit]This section lists the certificate verification functionality available in the various implementations.
| Implementation | RSA[38] | RSA-EXPORT (insecure)[38] | DHE-RSA (forward secrecy)[38] | DHE-DSS (forward secrecy)[38] | ECDH-ECDSA[88] | ECDHE-ECDSA (forward secrecy)[88] | ECDH-RSA[88] | ECDHE-RSA (forward secrecy)[88] | GOST R 34.10-94, 34.10-2001[89] |
|---|---|---|---|---|---|---|---|---|---|
| Botan | Disabled by default | No | Yes | Disabled by default | No | Yes | No | Yes | No |
| BSAFE | Yes | No | Yes | Yes | Yes | Yes | Yes | Yes | No |
| cryptlib | Yes | No | Yes | Yes | Yes | Yes | No | Yes | No |
| GnuTLS | Yes | No | Yes | Disabled by default[42] | No | Yes | No | Yes | No |
| JSSE | Yes | Disabled by default | Yes | Yes | Yes | Yes | Yes | Yes | No |
| LibreSSL | Yes | No[46] | Yes | Yes | No | Yes | No | Yes | Yes[90] |
| MatrixSSL | Yes | No | Yes | No | Yes | Yes | Yes | Yes | No |
| Mbed TLS | Yes | No | Yes | No | Yes | Yes | Yes | Yes | No |
| NSS | Yes | Disabled by default | Yes[91] | Yes | Yes | Yes | Yes | Yes | No[92][93] |
| OpenSSL | Yes | No[57] | Yes | Disabled by default[57] | No | Yes | No | Yes | Yes[94] |
| Rustls | No | No | No | No | No | Yes[60] | No | Yes[60] | No |
| Schannel XP/2003 | Yes | Yes | No | XP: Max 1024 bits 2003: 1024 bits only |
No | No | No | No | No[95] |
| Schannel Vista/2008 | Yes | Disabled by default | No | 1024 bits by default[96] | No | Yes | No | except AES_GCM | No[95] |
| Schannel 8/2012 | Yes | Disabled by default | AES_GCM only[97][98][99] | 1024 bits by default[96] | No | Yes | No | except AES_GCM | No[95] |
| Schannel 7/2008R2, 8.1/2012R2 | Yes | Disabled by default | Yes | 2048 bits by default[96] | No | Yes | No | except AES_GCM | No[95] |
| Schannel 10 | Yes | Disabled by default | Yes | 2048 bits by default[96] | No | Yes | No | Yes | No[95] |
| Secure Transport OS X 10.6 | Yes | Yes | except AES_GCM | Yes | Yes | except AES_GCM | yes | except AES_GCM | No |
| Secure Transport OS X 10.8-10.10 | Yes | No | except AES_GCM | No | Yes | except AES_GCM | Yes | except AES_GCM | No |
| Secure Transport OS X 10.11 | Yes | No | Yes | No | No | Yes | No | Yes | No |
| wolfSSL | Yes | No | Yes | No | Yes | Yes | Yes | Yes | No |
| Erlang/OTP SSL application | Yes | No | Yes | Yes | Yes | Yes | Yes | Yes | No |
| Implementation | RSA[38] | RSA-EXPORT (insecure)[38] | DHE-RSA (forward secrecy)[38] | DHE-DSS (forward secrecy)[38] | ECDH-ECDSA[88] | ECDHE-ECDSA (forward secrecy)[88] | ECDH-RSA[88] | ECDHE-RSA (forward secrecy)[88] | GOST R 34.10-94, 34.10-2001[89] |
Key exchange algorithms (alternative key-exchanges)
[edit]| Implementation | SRP[100] | SRP-DSS[100] | SRP-RSA[100] | PSK-RSA[101] | PSK[101] | DHE-PSK (forward secrecy)[101] | ECDHE-PSK (forward secrecy)[102] | KRB5[103] | DH-ANON[38] (insecure) | ECDH-ANON[88] (insecure) |
|---|---|---|---|---|---|---|---|---|---|---|
| Botan | No | No | No | No | Yes | No | Yes | No | No | No |
| BSAFE SSL-J | No | No | No | No | Yes[104] | No | No | No | Disabled by default | Disabled by default |
| cryptlib | No | No | No | No | Yes | Yes | No | No | No | No |
| GnuTLS | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | Disabled by default | Disabled by default |
| JSSE | No | No | No | No | No | No | No | No | Disabled by default | Disabled by default |
| LibreSSL | No[105] | No[105] | No[105] | No | No | No | No | No | Yes | Yes |
| MatrixSSL | No | No | No | Yes | Yes | Yes | No | No | Disabled by default | No |
| Mbed TLS | No | No | No | Yes | Yes | Yes | Yes | No | No | No |
| NSS | No[106] | No[106] | No[106] | No[107] | No[107] | No[107] | No[107] | No | Client side only, disabled by default[108] | Disabled by default[109] |
| OpenSSL | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes[110] | Disabled by default[111] | Disabled by default[111] |
| Rustls | No | No | No | No | No | No | No | No | No | No |
| Schannel | No | No | No | No | No | No | No | Yes | No | No |
| Secure Transport | No | No | No | No | No | No | No | Unknown | Yes | Yes |
| wolfSSL | Yes | Yes | Yes | Yes | Yes | Yes | Yes[112] | Yes | No | No |
| Erlang/OTP SSL application | Disabled by default | Disabled by default | Disabled by default | Disabled by default | Disabled by default | Disabled by default | No | No | Disabled by default | Disabled by default |
| Implementation | SRP[100] | SRP-DSS[100] | SRP-RSA[100] | PSK-RSA[101] | PSK[101] | DHE-PSK (forward secrecy)[101] | ECDHE-PSK (forward secrecy)[102] | KRB5[103] | DH-ANON[38] (insecure) | ECDH-ANON[88] (insecure) |
Certificate verification methods
[edit]| Implementation | Application-defined | PKIX path validation[113] | CRL[114] | OCSP[115] | DANE (DNSSEC)[116][117] | CT[118] |
|---|---|---|---|---|---|---|
| Botan | Yes | Yes | Yes | Yes | No | Unknown |
| Bouncy Castle | Yes | Yes | Yes | Yes | Yes | Unknown |
| BSAFE | Yes | Yes | Yes | Yes | No | Unknown |
| cryptlib | Yes | Yes | Yes | Yes | No | Unknown |
| GnuTLS | Yes | Yes | Yes | Yes | Yes | Unknown |
| JSSE | Yes | Yes | Yes | Yes | No | No |
| LibreSSL | Yes | Yes | Yes | Yes | No | Unknown |
| MatrixSSL | Yes | Yes | Yes | Yes[119] | No | Unknown |
| Mbed TLS | Yes | Yes | Yes | No[120] | No | Unknown |
| NSS | Yes | Yes | Yes | Yes | No[121] | Unknown |
| OpenSSL | Yes | Yes | Yes | Yes | Yes | Yes |
| Rustls | Yes | Yes | Yes | No | No | No |
| s2n | No [122] | Unknown [123] | Unknown [124] | |||
| Schannel | Unknown | Yes | Yes[125] | Yes[125] | No | Unknown |
| Secure Transport | Yes | Yes | Yes | Yes | No | Unknown |
| wolfSSL | Yes | Yes | Yes | Yes | No | Unknown |
| Erlang/OTP SSL application | Yes | Yes | Yes | No | No | Unknown |
| Implementation | Application-defined | PKIX path validation | CRL | OCSP | DANE (DNSSEC) | CT |
Encryption algorithms
[edit]| Implementation | Block cipher with mode of operation | Stream cipher | None | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| AES GCM [126] |
AES CCM [127] |
AES CBC | Camellia GCM [128] |
Camellia CBC [129][128] |
ARIA GCM [130] |
ARIA CBC [130] |
SEED CBC [131] |
3DES EDE CBC (insecure)[132] |
GOST 28147-89 CNT (proposed) [89][n 1] |
ChaCha20-Poly1305 [133] |
Null (insecure) [n 2] | |
| Botan | Yes | Yes | Yes | Yes | Yes | No | No | Disabled by default | Disabled by default | No | Yes[134] | Not implemented |
| BoringSSL | Yes | No | Yes | No | No | No | No | No | Yes | No | Yes | |
| BSAFE SSL-J | Yes | Yes | Yes | No | No | No | No | No | Disabled by default | No | No | Disabled by default |
| cryptlib | Yes | No | Yes | No | No | No | No | No | Yes | No | No | Not implemented |
| GnuTLS | Yes | Yes[42] | Yes | Yes | Yes | No | No | No | Disabled by default[135] | No | Yes[136] | Disabled by default |
| JSSE | Yes | No | Yes | No | No | No | No | No | Disabled by default[137] | No | Yes (JDK 12+)[138] |
Disabled by default |
| LibreSSL | Yes[46] | No | Yes | No | Yes[90] | No | No | No[46] | Yes | Yes[90] | Yes[46] | Disabled by default |
| MatrixSSL | Yes | No | Yes | No | No | No | No | Yes | Disabled by default | No | Yes[139] | Disabled by default |
| Mbed TLS | Yes | Yes [140] | Yes | Yes | Yes | Yes[141] | Yes[141] | No | No[50] | No | Yes[142] | Disabled by default at compile time |
| NSS | Yes[143] | No | Yes | No[144][n 3] | Yes[145] | No | No | Yes[146] | Yes | No[92][93] | Yes[147] | Disabled by default |
| OpenSSL | Yes[148] | Disabled by default[57] | Yes | No | Disabled by default[57] | Disabled by default[149] | No | Disabled by default[57] | Disabled by default[57] | Yes[94] | Yes[57] | Disabled by default |
| Rustls | Yes[60] | No | No | No | No | No | No | No | No | No | Yes[60] | Not implemented |
| Schannel XP/2003 | No | No | 2003 only[150] | No | No | No | No | No | Yes | No[95] | No | Disabled by default |
| Schannel Vista/2008, 2008R2, 2012 | No | No | Yes | No | No | No | No | No | Yes | No[95] | No | Disabled by default |
| Schannel 7, 8, 8.1/2012R2 | Yes except ECDHE_RSA [97][98] |
No | Yes | No | No | No | No | No | Yes | No[95] | No | Disabled by default |
| Schannel 10[151] | Yes | No | Yes | No | No | No | No | No | Yes | No[95] | No | Disabled by default |
| Secure Transport OS X 10.6 - 10.10 | No | No | Yes | No | No | No | No | No | Yes | No | No | Disabled by default |
| Secure Transport OS X 10.11 | Yes | No | Yes | No | No | No | No | No | Yes | No | No | Disabled by default |
| wolfSSL | Yes | Yes | Yes | No | No | No | No | No | Yes | No | Yes | Disabled by default |
| Erlang/OTP SSL application | Yes | No | Yes | No | No | No | No | No | Disabled by default | No | Experimental | Disable by default |
| Implementation | Block cipher with mode of operation | Stream cipher | None | |||||||||
| AES GCM [126] |
AES CCM [127] |
AES CBC | Camellia GCM [128] |
Camellia CBC [129][128] |
ARIA GCM [130] |
ARIA CBC [130] |
SEED CBC [131] |
3DES EDE CBC (insecure)[132] |
GOST 28147-89 CNT (proposed) [89][n 1] |
ChaCha20-Poly1305 [133] |
Null (insecure) [n 2] | |
- Notes
Obsolete algorithms
[edit]| Implementation | Block cipher with mode of operation | Stream cipher | ||||
|---|---|---|---|---|---|---|
| IDEA CBC [n 1](insecure)[153] |
DES CBC (insecure) [n 1] |
DES-40 CBC (EXPORT, insecure) [n 2] |
RC2-40 CBC (EXPORT, insecure) [n 2] |
RC4-128 (insecure) [n 3] |
RC4-40 (EXPORT, insecure) [n 4][n 2] | |
| Botan | No | No | No | No | No[154] | No |
| BoringSSL | No | No | No | No | Disabled by default at compile time | No |
| BSAFE SSL-J | No | Disabled by default | Disabled by default | No | Disabled by default | Disabled by default |
| cryptlib | No | Disabled by default at compile time | No | No | Disabled by default at compile time | No |
| GnuTLS | No | No | No | No | Disabled by default[42] | No |
| JSSE | No | Disabled by default | Disabled by default | No | Disabled by default | Disabled by default [155] |
| LibreSSL | Yes | Yes | No[46] | No[46] | Yes | No[46] |
| MatrixSSL | Yes | No | No | No | Disabled by default | No |
| Mbed TLS | No | Disabled by default at compile time | No | No | Disabled by default at compile time[51] | No |
| NSS | Yes | Disabled by default | Disabled by default | Disabled by default | Lowest priority[156][157] | Disabled by default |
| OpenSSL | Disabled by default[57] | Disabled by default | No[57] | No[57] | Disabled by default | No[57] |
| Rustls | No | No | No | No | No | No |
| Schannel XP/2003 | No | Yes | Yes | Yes | Yes | Yes |
| Schannel Vista/2008 | No | Disabled by default | Disabled by default | Disabled by default | Yes | Disabled by default |
| Schannel 7/2008R2 | No | Disabled by default | Disabled by default | Disabled by default | Lowest priority will be disabled soon[158] |
Disabled by default |
| Schannel 8/2012 | No | Disabled by default | Disabled by default | Disabled by default | Only as fallback | Disabled by default |
| Schannel 8.1/2012R2 | No | Disabled by default | Disabled by default | Disabled by default | Disabled by default[158] | Disabled by default |
| Schannel 10[151] | No | Disabled by default | Disabled by default | Disabled by default | Disabled by default[158] | Disabled by default |
| Secure Transport OS X 10.6 | Yes | Yes | Yes | Yes | Yes | Yes |
| Secure Transport OS X 10.7 | Yes | Unknown | Unknown | Unknown | Yes | Unknown |
| Secure Transport OS X 10.8-10.9 | Yes | Disabled by default | Disabled by default | Disabled by default | Yes | Disabled by default |
| Secure Transport OS X 10.10-10.11 | Yes | Disabled by default | Disabled by default | Disabled by default | Lowest priority | Disabled by default |
| Secure Transport macOS 10.12 | Yes | Disabled by default | Disabled by default | Disabled by default | Disabled by default | Disabled by default |
| wolfSSL | Disabled by default[159] | No | No | No | Disabled by default | No |
| Erlang/OTP SSL application | no | Disabled by default | no | no | Disabled by default | no |
| Implementation | Block cipher with mode of operation | Stream cipher | ||||
| IDEA CBC [n 1](insecure)[153] |
DES CBC (insecure) [n 1] |
DES-40 CBC (EXPORT, insecure) [n 2] |
RC2-40 CBC (EXPORT, insecure) [n 2] |
RC4-128 (insecure) [n 3] |
RC4-40 (EXPORT, insecure) [n 4][n 2] | |
- Notes
- ^ a b c d IDEA and DES have been removed from TLS 1.2.[152]
- ^ a b c d e f 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.
- ^ a b The RC4 attacks weaken or break RC4 used in SSL/TLS. Use of RC4 is prohibited by RFC 7465.
- ^ a b The RC4 attacks weaken or break RC4 used in SSL/TLS.
Supported elliptic curves
[edit]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)
[edit]| applicable TLS version | TLS 1.3 and earlier | TLS 1.2 and earlier | ||||||
|---|---|---|---|---|---|---|---|---|
| Implementation | secp256r1 prime256v1 NIST P-256 (0x0017,[160] 23[161]) |
secp384r1 NIST P-384 (0x0018,[160] 24[161]) |
secp521r1 NIST P-521 (0x0019,[160] 25[161]) |
X25519 (0x001D,[160] 29[161]) |
X448 (0x001E,[160] 30[161]) |
brainpoolP256r1 (26)[162] |
brainpoolP384r1 (27)[162] |
brainpoolP512r1 (28)[162] |
| Botan | Yes | Yes | Yes | Yes[134] | No | Yes[163] | Yes[163] | Yes[163] |
| BoringSSL | Yes | Yes | Yes (disabled by default) | Yes | No | No | No | No |
| BSAFE | Yes | Yes | Yes | No | No | No | No | No |
| GnuTLS | Yes | Yes | Yes | Yes[164] | Yes[165] | No | No | No |
| JSSE | Yes | Yes | Yes | Yes x25519: JDK 13+[166] Ed25519:JDK 15+[167] |
Yes x448: JDK 13+[166] Ed448: JDK 15+[167] |
No | No | No |
| LibreSSL | Yes | Yes | Yes | Yes[168] | No | Yes[46] | Yes[46] | Yes[46] |
| MatrixSSL | Yes | Yes | Yes | TLS 1.3 only[169] | No | Yes | Yes | Yes |
| Mbed TLS | Yes | Yes | Yes | Primitive only[170] | Primitive only[171] | Yes[172] | Yes[172] | Yes[172] |
| NSS | Yes | Yes | Yes | Yes[173] | No[174][175] | No[176] | No[176] | No[176] |
| OpenSSL | Yes | Yes | Yes | Yes[177][178] | Yes[179][180] | Yes[59] | Yes[59] | Yes[59] |
| Rustls | Yes | Yes | No | Yes | No | No | No | No |
| Schannel Vista/2008, 7/2008R2, 8/2012, 8.1/2012R2, 10 | Yes | Yes | Yes | No | No | No | No | No |
| Secure Transport | Yes | Yes | Yes | No | No | No | No | No |
| wolfSSL | Yes | Yes | Yes | Yes[181] | Yes[182] | Yes | Yes | Yes |
| Erlang/OTP SSL application | Yes | Yes | Yes | No | No | Yes | Yes | Yes |
| Implementation | secp256r1 prime256v1 NIST P-256 (0x0017, 23) |
secp384r1 NIST P-384 (0x0018, 24) |
secp521r1 NIST P-521 (0x0019, 25) |
X25519 (0x001D, 29) |
X448 (0x001E, 30) |
brainpoolP256r1 (26) |
brainpoolP384r1 (27) |
brainpoolP512r1 (28) |
Deprecated curves in RFC 8422
[edit]| Implementation | sect163k1 NIST K-163 (1)[88] |
sect163r1 (2)[88] |
sect163r2 NIST B-163 (3)[88] |
sect193r1 (4)[88] |
sect193r2 (5)[88] |
sect233k1 NIST K-233 (6)[88] |
sect233r1 NIST B-233 (7)[88] |
sect239k1 (8)[88] |
sect283k1 NIST K-283 (9)[88] |
sect283r1 NIST B-283 (10)[88] |
sect409k1 NIST K-409 (11)[88] |
sect409r1 NIST B-409 (12)[88] |
sect571k1 NIST K-571 (13)[88] |
sect571r1 NIST B-571 (14)[88] |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Botan | No | No | No | No | No | No | No | No | No | No | No | No | No | No |
| BoringSSL | No | No | No | No | No | No | No | No | No | No | No | No | No | No |
| BSAFE | Yes | No | Yes | No | No | Yes | Yes | No | Yes | Yes | Yes | Yes | Yes | Yes |
| GnuTLS | No | No | No | No | No | No | No | No | No | No | No | No | No | No |
| JSSE | Notes[a][b] | Notes[a][b] | Notes[a][b] | Notes[a][b] | Notes[a][b] | Notes[a][b] | Notes[a][b] | Notes[a][b] | Notes[a][b] | Notes[a][b] | Notes[a][b] | Notes[a][b] | Notes[a][b] | Notes[a][b] |
| LibreSSL | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| MatrixSSL | No | No | No | No | No | No | No | No | No | No | No | No | No | No |
| Mbed TLS | No | No | No | No | No | No | No | No | No | No | No | No | No | No |
| NSS | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| OpenSSL | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| Rustls | No | No | No | No | No | No | No | No | No | No | No | No | No | No |
| Schannel Vista/2008, 7/2008R2, 8/2012, 8.1/2012R2, 10 | No | No | No | No | No | No | No | No | No | No | No | No | No | No |
| Secure Transport | No | No | No | No | No | No | No | No | No | No | No | No | No | No |
| wolfSSL | No | No | No | No | No | No | No | No | No | No | No | No | No | No |
| Erlang/OTP SSL application | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| Implementation | sect163k1 NIST K-163 (1) |
sect163r1 (2) |
sect163r2 NIST B-163 (3) |
sect193r1 (4) |
sect193r2 (5) |
sect233k1 NIST K-233 (6) |
sect233r1 NIST B-233 (7) |
sect239k1 (8) |
sect283k1 NIST K-283 (9) |
sect283r1 NIST B-283 (10) |
sect409k1 NIST K-409 (11) |
sect409r1 NIST B-409 (12) |
sect571k1 NIST K-571 (13) |
sect571r1 NIST B-571 (14) |
| Implementation | secp160k1 (15)[88] |
secp160r1 (16)[88] |
secp160r2 (17)[88] |
secp192k1 (18)[88] |
secp192r1 prime192v1 NIST P-192 (19)[88] |
secp224k1 (20)[88] |
secp224r1 NIST P-244 (21)[88] |
secp256k1 (22)[88] |
arbitrary prime curves (0xFF01)[88][185] |
arbitrary char2 curves (0xFF02)[88][185] |
|---|---|---|---|---|---|---|---|---|---|---|
| Botan | No | No | No | No | No | No | No | No | No | No |
| BoringSSL | No | No | No | No | No | No | Yes | No | No | No |
| BSAFE | No | No | No | No | Yes | No | Yes | No | No | No |
| GnuTLS | No | No | No | No | Yes | No | Yes | No | No | No |
| JSSE | Notes[a][b] | Notes[a][b] | Notes[a][b] | Notes[a][b] | Notes[a][b] | Notes[a][b] | Notes[a][b] | Notes[a][b] | No | No |
| LibreSSL | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | No |
| MatrixSSL | No | No | No | No | Yes | No | Yes | No | No | No |
| Mbed TLS | No | No | No | Yes | Yes | Yes | Yes | Yes | No | No |
| NSS | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | No |
| OpenSSL | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | No |
| Rustls | No | No | No | No | No | No | No | No | No | No |
| Schannel Vista/2008, 7/2008R2, 8/2012, 8.1/2012R2, 10 | No | No | No | No | No | No | No | No | No | No |
| Secure Transport | No | No | No | No | Yes | No | No | No | No | No |
| wolfSSL | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | No |
| Erlang/OTP SSL application | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No | No |
| Implementation | secp160k1 (15) |
secp160r1 (16) |
secp160r2 (17) |
secp192k1 (18) |
secp192r1 prime192v1 NIST P-192 (19) |
secp224k1 (20) |
secp224r1 NIST P-244 (21) |
secp256k1 (22) |
arbitrary prime curves (0xFF01) |
arbitrary char2 curves (0xFF02) |
- Notes
Data integrity
[edit]| Implementation | HMAC-MD5 | HMAC-SHA1 | HMAC-SHA256/384 | AEAD | GOST 28147-89 IMIT [89] |
GOST R 34.11-94 [89] |
|---|---|---|---|---|---|---|
| Botan | No | Yes | Yes | Yes | No | No |
| BSAFE | Yes | Yes | Yes | Yes | No | No |
| cryptlib | Yes | Yes | Yes | Yes | No | No |
| GnuTLS | Yes | Yes | Yes | Yes | No | No |
| JSSE | Disabled by Default | Yes | Yes | Yes | No | No |
| LibreSSL | Yes | Yes | Yes | Yes | Yes [90] |
Yes [90] |
| MatrixSSL | Yes | Yes | Yes | Yes | No | No |
| Mbed TLS | Yes | Yes | Yes | Yes | No | No |
| NSS | Yes | Yes | Yes | Yes | No [92][93] |
No [92][93] |
| OpenSSL | Yes | Yes | Yes | Yes | Yes [94] |
Yes [94] |
| Rustls | No | No | No | Yes | No | No |
| Schannel XP/2003, Vista/2008 | Yes | Yes | XP SP3, 2003 SP2 via hotfix [186] |
No | No [95] |
No [95] |
| Schannel 7/2008R2, 8/2012, 8.1/2012R2 | Yes | Yes | Yes | except ECDHE_RSA [97][98][99] |
No [95] |
No [95] |
| Schannel 10 | Yes | Yes | Yes | Yes [151] |
No [95] |
No [95] |
| Secure Transport | Yes | Yes | Yes | Yes | No | No |
| wolfSSL | Disabled by Default | Yes | Yes | Yes | No | No |
| Erlang/OTP SSL application | Yes | Yes | Yes | Yes | No | No |
| Implementation | HMAC-MD5 | HMAC-SHA1 | HMAC-SHA256/384 | AEAD | GOST 28147-89 IMIT | GOST R 34.11-94 |
Compression
[edit]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.
| Implementation | DEFLATE[187] (insecure) |
|---|---|
| Botan | No |
| BSAFE[41] | No |
| cryptlib | No |
| GnuTLS | Disabled by default |
| JSSE | No |
| LibreSSL | No[46] |
| MatrixSSL | Disabled by default |
| Mbed TLS | Disabled by default |
| NSS | Disabled by default |
| OpenSSL | Disabled by default |
| Rustls | No |
| Schannel | No |
| Secure Transport | No |
| wolfSSL | Disabled by default |
| Erlang/OTP SSL application | No |
| Implementation | DEFLATE |
Extensions
[edit]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.
| Implementation | Secure Renegotiation [188] |
Server Name Indication [189] |
ALPN [190] |
Certificate Status Request [189] |
OpenPGP [191] |
Supplemental Data [192] |
Session Ticket [193] |
Keying Material Exporter [194] |
Maximum Fragment Length [189] |
Encrypt-then-MAC [29] |
TLS Fallback SCSV [195] |
Extended Master Secret [196] |
ClientHello Padding [197] |
Raw Public Keys [198] |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Botan | Yes | Yes | Yes[199] | No | No | No | Yes | Yes | Yes | Yes | Yes[200] | Yes[201] | No | Unknown |
| BSAFE SSL-J | Yes | Yes | No | Yes | No | No | No | No | Yes | No | No | Yes | No | No |
| cryptlib | Yes | Yes | No | No | No | Yes | No | No | No[202] | Yes | Yes | Yes | No | Unknown |
| GnuTLS | Yes | Yes | Yes[203] | Yes | No[204] | Yes | Yes | Yes | Yes | Yes[42] | Yes[205] | Yes[42] | Yes[206] | Yes[207] |
| JSSE | Yes | Yes[72] | Yes[72] | Yes | No | No | Yes | No | Yes | No | No | Yes | No | No |
| LibreSSL | Yes | Yes | Yes[208] | Yes | No | No? | Yes | Yes? | No | No | Server side only[209] | No | Yes | No |
| MatrixSSL | Yes | Yes | Yes[210] | Yes[139] | No | No | Yes | No | Yes | No | Yes[139] | Yes[139] | No | Unknown |
| Mbed TLS | Yes | Yes | Yes[211] | No | No | No | Yes | No | Yes | Yes[212] | Yes[212] | Yes[212] | No | No |
| NSS | Yes | Yes | Yes[213] | Yes | No[214] | No | Yes | Yes | No | No[215] | Yes[216] | Yes[217] | Yes[213] | Unknown |
| OpenSSL | Yes | Yes | Yes[59] | Yes | No | No? | Yes | Yes | Yes | Yes | Yes[218] | Yes[57] | Yes[219] | Yes[220] |
| Rustls | Yes | Yes | Yes | Yes | No | No | Yes | Yes | No | No | No [221] | Yes | No | Unknown |
| Schannel XP/2003 | No | No | No | No | No | Yes | No | No | No | No | No | No | No | Unknown |
| Schannel Vista/2008 | Yes | Yes | No | No | No | Yes | No | No | No | No | No | Yes[222] | No | Unknown |
| Schannel 7/2008R2 | Yes | Yes | No | Yes | No | Yes | No | No | No | No | No | Yes[222] | No | Unknown |
| Schannel 8/2012 | Yes | Yes | No | Yes | No | Yes | Client side only[223] | No | No | No | No | Yes[222] | No | Unknown |
| Schannel 8.1/2012R2, 10 | Yes | Yes | Yes | Yes | No | Yes | Yes[223] | No | No | No | No | Yes[222] | No | Unknown |
| Secure Transport | Yes | Yes | Unknown | No | No | Yes | No | No | No | No | No | No | No | Unknown |
| wolfSSL | Yes | Yes | Yes[159] | Yes | No | No | Yes | No | Yes | Yes[224] | No | Yes | No | Yes[225] |
| Erlang/OTP SSL application | Yes | Yes | Yes | No | No | No | No | No | No | No | Yes | No | No | Unknown |
| Implementation | Secure Renegotiation | Server Name Indication | ALPN | Certificate Status Request | OpenPGP | Supplemental Data | Session Ticket | Keying Material Exporter | Maximum Fragment Length | Encrypt-then-MAC | TLS Fallback SCSV | Extended Master Secret | ClientHello Padding | Raw Public Keys |
Assisted cryptography
[edit]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.
| Implementation | PKCS #11 device | Intel AES-NI | VIA PadLock | ARMv8-A | Intel SHA | NXP CAAM | TPM 2.0 | NXP SE050 | Microchip ATECC | STMicro STSAFE | Maxim MAXQ |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Botan | Yes[226] | Yes | No | Yes | No | Yes[227] | No | No | No | No | |
| BSAFE SSL-J [a][b] | Yes | Yes | No | Yes | Yes | No | No[230] | No | No | No | No |
| cryptlib | Yes | Yes | Yes | No | Yes | No | No | No | No | ||
| Crypto++ | Yes | Yes | No | No | No | No | |||||
| GnuTLS | Yes | Yes | Yes | Yes[231] | Yes | No[232] | No | No | No | No | |
| JSSE | Yes | Yes[233] | No | No | No | No | No | No | No | ||
| LibreSSL | No | Yes | Yes | No | No | No | No | No | |||
| MatrixSSL | Yes | Yes | No | Yes | No | No | No | No | No | ||
| Mbed TLS | Yes | Yes[234] | Yes | No | No | Partial[235] | Yes[236] | No | No | ||
| NSS | Yes[237] | Yes[238] | No[239] | No | No | No | No | No | No | ||
| OpenSSL | Yes[240][241][242] | Yes | Yes | Yes[243] | Yes | Partial | Partial[244][245] | Partial[235] | No | Partial[246] | No |
| Rustls | Yes | Yes | Yes | No | No | No | No | ||||
| Schannel | No | Yes | No | No | No | No | No | No | No | ||
| Secure Transport | No | Yes[247][248] | No | Yes | No | No | No | No | No | ||
| wolfSSL | Yes | Yes | No | Yes | Yes | Yes[249] | Yes[250][251] | Yes[252] | Yes[253] | Yes[254] | Yes[255] |
| Implementation | PKCS #11 device | Intel AES-NI | VIA PadLock | ARMv8-A | Intel SHA | NXP CAAM | TPM 2.0 | NXP SE050 | Microchip ATECC | STMicro STSAFE | Maxim MAXQ |
System-specific backends
[edit]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.
| Implementation | /dev/crypto | af_alg | Windows CSP | CommonCrypto | OpenSSL engine |
|---|---|---|---|---|---|
| Botan | No | No | No | No | Partial |
| BSAFE | No | No | No | No | No |
| cryptlib | Yes | No | No | No | No |
| GnuTLS | Yes | Yes | No | No | No |
| JSSE | No | No | Yes | No | No |
| LibreSSL | No | No | No | No | No[256] |
| MatrixSSL | No | No | No | Yes | Yes |
| Mbed TLS | No | No | No | No | No |
| NSS | No | No | No | No | No |
| OpenSSL | Yes | Yes | No | No | Yes |
| Rustls | No | Yes [257] | No | No | No |
| Schannel | No | No | Yes | No | No |
| Secure Transport | No | No | No | Yes | No |
| wolfSSL | Yes | Yes | Partial | No | Yes[258] |
| Erlang/OTP SSL application | No | No | No | No | Yes |
| Implementation | /dev/crypto | af_alg | Windows CSP | CommonCrypto | OpenSSL engine |
Cryptographic module/token support
[edit]| Implementation | TPM support | Hardware token support | Objects identified via |
|---|---|---|---|
| Botan | Partial[201] | PKCS #11 | |
| BSAFE SSL-J | No | No | |
| cryptlib | Yes | PKCS #11 | User-defined label |
| GnuTLS | Yes | PKCS #11 | RFC 7512 PKCS #11 URLs[259] |
| JSSE | No | PKCS11 Java Cryptography Architecture, Java Cryptography Extension |
|
| LibreSSL | Yes | PKCS #11 (via 3rd party module) | Custom method |
| MatrixSSL | No | PKCS #11 | |
| Mbed TLS | No | PKCS #11 (via libpkcs11-helper) or standard hooks | Custom method |
| NSS | No | PKCS #11 | |
| OpenSSL | Yes | PKCS #11 (via 3rd party module)[260] | RFC 7512 PKCS #11 URLs[259] |
| Rustls | No | Microsoft CryptoAPI [261] | Custom method |
| Schannel | No | Microsoft CryptoAPI | UUID, User-defined label |
| Secure Transport | |||
| wolfSSL | Yes | PKCS #11 | |
| Implementation | TPM support | Hardware token support | Objects identified via |
Code dependencies
[edit]| Implementation | Dependencies | Optional dependencies |
|---|---|---|
| Botan | C++20 | SQLite zlib (compression) bzip2 (compression) liblzma (compression) boost trousers (TPM) |
| GnuTLS | libc nettle gmp |
zlib (compression) p11-kit (PKCS #11) trousers (TPM) libunbound (DANE) |
| JSSE | Java | |
| MatrixSSL | none | zlib (compression) |
| MatrixSSL-open | libc or newlib | |
| Mbed TLS | libc | libpkcs11-helper (PKCS #11) zlib (compression) |
| NSS | libc libnspr4 libsoftokn3 libplc4 libplds4 |
zlib (compression) |
| Rustls | rust core library | rust std library zlib-rs (compression) brotli (compression) ring (cryptography) aws-lc-rs (cryptography) |
| OpenSSL | libc | zlib (compression) brotli (compression) zstd (compression) |
| wolfSSL | None | libc zlib (compression) |
| Erlang/OTP SSL application | libcrypto (from OpenSSL), Erlang/OTP and its public_key, crypto and asn1 applications | Erlang/OTP -inets (http fetching of CRLs) |
| Implementation | Dependencies | Optional dependencies |
Development environment
[edit]| Implementation | Namespace | Build tools | API manual | Crypto back-end | OpenSSL compatibility Layer[clarify] |
|---|---|---|---|---|---|
| Botan | Botan::TLS | Makefile | Sphinx | Included (pluggable) | No |
| Bouncy Castle | org.bouncycastle | Java Development Environment | Programmers reference manual (PDF) | Included (pluggable) | No |
| BSAFE SSL-J | com.rsa.asn1[a] com.rsa.certj[b] |
Java class loader | Javadoc, Developer's guide (HTML) | Included | No |
| cryptlib | crypt* | makefile, MSVC project workspaces | Programmers reference manual (PDF), architecture design manual (PDF) | Included (monolithic) | No |
| GnuTLS | gnutls_* | Autoconf, automake, libtool | Manual and API reference (HTML, PDF) | External, libnettle | Yes (limited) |
| JSSE | javax.net.ssl sun.security.ssl |
Makefile | API Reference (HTML) + | Java Cryptography Architecture, Java Cryptography Extension |
No |
| MatrixSSL | matrixSsl_* ps* |
Makefile, MSVC project workspaces, Xcode projects for OS X and iOS | API Reference (PDF), Integration Guide | Included (pluggable) | Yes (Subset: SSL_read, SSL_write, etc.) |
| Mbed TLS | mbedtls_ssl_* mbedtls_sha1_* |
Makefile, CMake, MSVC project workspaces, yotta | API Reference + High Level and Module Level Documentation (HTML) | Included (monolithic) | No |
| NSS | CERT_* SEC_* |
Makefile | Manual (HTML) | Included, PKCS#11 based[262] | Yes (separate package called nss_compat_ossl[263]) |
| OpenSSL | SSL_* SHA1_* |
Makefile | Man pages | Included (monolithic) | N/a |
| Rustls | rustls::
|
cargo | API reference and design manual | Two options included (pluggable) | Yes[264] (subset) |
| wolfSSL | wolfSSL_* CyaSSL_* |
Autoconf, automake, libtool, MSVC project workspaces, XCode projects, CodeWarrior projects, MPLAB X projects, Keil, IAR, Clang, GCC, e2Studio | Manual and API Reference (HTML, PDF) | Included (monolithic) | Yes (about 60% of API) |
| Implementation | Namespace | Build tools | API manual | Crypto back-end | OpenSSL compatibility layer |
Portability concerns
[edit]| Implementation | Platform requirements | Network requirements | Thread safety | Random seed | Able to cross-compile | No OS (bare metal) | Supported operating systems |
|---|---|---|---|---|---|---|---|
| Botan | C++11 | None | Thread-safe | Platform-dependent | Yes | Windows, Linux, macOS, Android, iOS, FreeBSD, OpenBSD, Solaris, AIX, HP-UX, QNX, BeOS, IncludeOS | |
| BSAFE SSL-J | Java | Java SE network components | Thread-safe | Depends on java.security.SecureRandom | Yes | No | FreeBSD, Linux, macOS, Microsoft Windows, Android, AIX, Solaris |
| cryptlib | C89 | POSIX send() and recv(). API to supply your own replacement | Thread-safe | Platform-dependent, including hardware sources | Yes | Yes | AMX, BeOS, ChorusOS, DOS, eCos, FreeRTOS/OpenRTOS, uItron, MVS, OS/2, Palm OS, QNX Neutrino, RTEMS, Tandem NonStop, ThreadX, uC/OS II, Unix (AIX, FreeBSD, HPUX, Linux, macOS, Solaris, etc.), VDK, VM/CMS, VxWorks, Win16, Win32, Win64, WinCE/PocketPC/etc, XMK |
| GnuTLS | C89 | POSIX send() and recv(). API to supply your own replacement. | Thread-safe, needs custom mutex hooks if neither POSIX nor Windows threads are available. | Platform dependent | Yes | No | Generally any POSIX platforms or Windows, commonly tested platforms include Linux, Win32/64, macOS, Solaris, OpenWRT, FreeBSD, NetBSD, OpenBSD. |
| JSSE | Java | Java SE network components | Thread-safe | Depends on java.security.SecureRandom | Yes | Java based, platform-independent | |
| MatrixSSL | C89 | None | Thread-safe | Platform dependent | Yes | Yes | All |
| Mbed TLS | C89 | POSIX read() and write(). API to supply your own replacement. | Threading layer available (POSIX or own hooks) | Random seed set through entropy pool | Yes | Yes | Known to work on: Win32/64, Linux, macOS, Solaris, FreeBSD, NetBSD, OpenBSD, OpenWRT, iPhone (iOS), Xbox, Android, eCos, SeggerOS, RISC OS |
| NSS | C89, NSPR[265] | NSPR[265] PR_Send() and PR_Recv(). API to supply your own replacement. | Thread-safe | Platform dependent[266] | Yes (but cumbersome) | No | AIX, Android, FreeBSD, NetBSD, OpenBSD, BeOS, HP-UX, IRIX, Linux, macOS, OS/2, Solaris, OpenVMS, Amiga DE, Windows, WinCE, Sony PlayStation |
| Rustls | Rust (programming language) | None | Thread-safe | Platform dependent | Yes | Yes | All supported by Rust (programming language) |
| OpenSSL | C89 | None | Thread-safe | Platform dependent | Yes | No | Unix-like, DOS (with djgpp), Windows, OpenVMS, NetWare, eCos |
| wolfSSL | C89 | POSIX send() and recv(). API to supply your own replacement. | Thread-safe | Random seed set through wolfCrypt | Yes | Yes | Win32/64, Linux, macOS, Solaris, ThreadX, VxWorks, FreeBSD, NetBSD, OpenBSD, embedded Linux, Yocto Project, OpenEmbedded, WinCE, Haiku, OpenWRT, iPhone (iOS), Android, Nintendo Wii and GameCube through DevKitPro, QNX, MontaVista, NonStop, TRON/ITRON/μITRON, eCos, Micrium μC/OS-III, FreeRTOS, SafeRTOS, NXP/Freescale MQX, Nucleus, TinyOS, HP/UX, AIX, ARC MQX, Keil RTX, TI-RTOS, uTasker, embOS, INtime, Mbed, uT-Kernel, RIOT, CMSIS-RTOS, FROSTED, Green Hills INTEGRITY, TOPPERS, PetaLinux, Apache mynewt |
| Implementation | Platform requirements | Network requirements | Thread safety | Random seed | Able to cross-compile | No OS (bare metal) | Supported operating systems |
See also
[edit]References
[edit]- ^ "Botan: Release Notes". Retrieved 2025-12-22.
- ^ "BoringSSL README.md". boringssl.googlesource.com. Retrieved 2025-11-11.
- ^ "Download Bouncy Castle for Java - bouncycastle.org". 2025-11-27. Retrieved 2025-12-01.
- ^ "Download Bouncy Castle for Java LTS - bouncycastle.org". 2025-09-19. Retrieved 2025-12-01.
- ^ "Download Bouncy Castle for Java FIPS - bouncycastle.org". 2024-07-30. Retrieved 2024-11-29.
- ^ "Download Bouncy Castle for C# .NET - bouncycastle.org". 2025-07-15. Retrieved 2025-12-01.
- ^ "Download Bouncy Castle for C# .NET FIPS - bouncycastle.org". 2024-03-11. Retrieved 2024-11-29.
- ^ "Dell BSAFE SSL-J 7.4 Release Advisory". Dell.
- ^ "Dell BSAFE Micro Edition Suite 5.0.3 Release Advisory".
- ^ Gutmann, Peter (May 1, 2025). "cryptlib". Github. Retrieved 2025-08-02.
- ^ Daiki Ueno (20 November 2025). "gnutls 3.8.11 released". Retrieved 20 November 2025.
- ^ "Java Development Kit 25 Release Notes". Oracle Corporation. Retrieved 2025-06-09.
- ^ "Java™ SE Development Kit 21, 21.0.5 Release Notes". Oracle Corporation. Retrieved 2024-10-16.
- ^ "Java™ SE Development Kit 17, 17.0.13 Release Notes". Oracle Corporation. Retrieved 2024-10-16.
- ^ "Java™ SE Development Kit 11, 11.0.25 Release Notes". Oracle Corporation. Retrieved 2024-10-16.
- ^ "Java™ SE Development Kit 8, Update 431 Release Notes". Oracle Corporation. Retrieved 2024-10-16.
- ^ "LibreSSL 4.1.2 and 4.2.1 released". 31 October 2025. Retrieved 3 November 2025.
- ^ The features listed are for the closed source version
- ^ "MatrixSSL 4.2.2 Open release". 2019-09-11. Retrieved 2020-03-20.
- ^ "Release 4.0.0". 15 October 2025. Retrieved 21 October 2025.
- ^ a b "NSS:Release versions". Mozilla Wiki. Retrieved 7 November 2022.
- ^ "OpenSSL 3.6.1". 27 January 2026. Retrieved 28 January 2026.
- ^ "rustls/rustls releases". Github. Retrieved 15 August 2025.
- ^ "wolfSSL product description". Retrieved 2016-05-03.
- ^ "wolfSSL Embedded SSL/TLS". Retrieved 2016-05-03.
- ^ "wolfSSL ChangeLog". 2025-11-20. Retrieved 2025-11-20.
- ^ Prohibiting Secure Sockets Layer (SSL) Version 2.0. doi:10.17487/RFC6176. RFC 6176.
- ^ Vaudenay, Serge (2001). "CBC-Padding: Security Flaws in SSL, IPsec, WTLS,..." (PDF).
- ^ a b Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security. doi:10.17487/RFC7366. RFC 7366.
- ^ "Rizzo/Duong BEAST Countermeasures". Archived from the original on 2016-03-11.
- ^ Möller, Bodo; Duong, Thai; Kotowicz, Krzysztof (September 2014). "This POODLE Bites: Exploiting The SSL 3.0 Fallback" (PDF). Archived from the original (PDF) on 15 October 2014. Retrieved 15 October 2014.
- ^ "TLSv1.2's Major Differences from TLSv1.1". The Transport Layer Security (TLS) Protocol Version 1.2. sec. 1.2. doi:10.17487/RFC5246. RFC 5246.
- ^ a b c RFC 6347. doi:10.17487/RFC6347.
- ^ a b Elgamal, Taher; Hickman, Kipp E. B. (19 April 1995). The SSL Protocol. I-D draft-hickman-netscape-ssl-00.
- ^ a b RFC 6101. doi:10.17487/RFC6101.
- ^ a b RFC 2246. doi:10.17487/RFC2246.
- ^ a b RFC 4346. doi:10.17487/RFC4346.
- ^ a b c d e f g h i j k l RFC 5246. doi:10.17487/RFC5246.
- ^ a b RFC 4347. doi:10.17487/RFC4347.
- ^ "Version 1.11.13, 2015-01-11 — Botan". 2015-01-11. Archived from the original on 2015-01-09. Retrieved 2015-01-16.
- ^ a b c "RSA BSAFE Technical Specification Comparison Tables" (PDF). Archived from the original (PDF) on 2015-09-24. Retrieved 2015-01-09.
- ^ a b c d e f "[gnutls-devel] GnuTLS 3.4.0 released". 2015-04-08. Retrieved 2015-04-16.
- ^ "[gnutls-devel] GnuTLS 3.6.3". 2018-07-16. Retrieved 2018-09-16.
- ^ "Java SE Development Kit 8, Update 31 Release Notes". Retrieved 2024-01-14.
- ^ a b "Release Note: Disable TLS 1.0 and 1.1". Retrieved 2024-01-14.
- ^ a b c d e f g h i j k l m "OpenBSD 5.6 Released". 2014-11-01. Retrieved 2015-01-20.
- ^ "LibreSSL 2.3.0 Released". 2015-09-23. Retrieved 2015-09-24.
- ^ "LibreSSL 3.3.3 Released". 2021-05-04. Retrieved 2021-05-04.
- ^ "MatrixSSL - News". Archived from the original on 2015-02-14. Retrieved 2014-11-09.
- ^ a b c d "Mbed TLS 3.0.0 branch released". GitHub. 2021-07-07. Retrieved 2021-08-13.
- ^ a b c "mbed TLS 2.0.0 released". 2015-07-10. Retrieved 2015-07-14.
- ^ "NSS 3.19 release notes". Mozilla Developer Network. Mozilla. Archived from the original on 2015-06-05. Retrieved 2015-05-06.
- ^ a b "NSS 3.14 release notes". Mozilla Developer Network. Mozilla. Archived from the original on 2013-01-17. Retrieved 2012-10-27.
- ^ "NSS 3.15.1 release notes". Mozilla Developer Network. Mozilla. Retrieved 2013-08-10.
- ^ "NSS 3.39 release notes". Mozilla Developer Network. Mozilla. 2018-08-31. Archived from the original on 2021-12-07. Retrieved 2018-09-15.
- ^ "NSS 3.16.2 release notes". Mozilla Developer Network. Mozilla. 2014-06-30. Archived from the original on 2021-12-07. Retrieved 2014-06-30.
- ^ a b c d e f g h i j k l m "OpenSSL 1.1.0 Series Release Notes". www.openssl.org. Archived from the original on 2018-03-17. Retrieved 2016-09-03.
- ^ a b "Major changes between OpenSSL 1.0.0h and OpenSSL 1.0.1 [14 Mar 2012]". 2012-03-14. Archived from the original on December 5, 2014. Retrieved 2015-01-20.
- ^ a b c d e f "Major changes between OpenSSL 1.0.1l and OpenSSL 1.0.2 [22 Jan 2015]". Archived from the original on September 4, 2014. Retrieved 2015-01-22.
- ^ a b c d e f g h i j k "rustls implemented and unimplemented features documentation". Retrieved 2024-08-28.
- ^ "S2N Readme". GitHub. 2019-12-21.
- ^ "TLS Cipher Suites (Windows)". msdn.microsoft.com. 14 July 2023.
- ^ a b "TLS Cipher Suites in Windows Vista (Windows)". msdn.microsoft.com. 25 October 2021.
- ^ a b c "Cipher Suites in TLS/SSL (Schannel SSP) (Windows)". msdn.microsoft.com. 14 July 2023.
- ^ a b "An update is available that adds support for DTLS in Windows 7 SP1 and Windows Server 2008 R2 SP1". Microsoft. Retrieved 13 November 2012.
- ^ "Protocols in TLS/SSL (Schannel SSP)". Microsoft. 2022-05-25. Retrieved 2023-11-18.
- ^ "Protocols in TLS/SSL (Schannel SSP)". 25 May 2022. Retrieved 6 November 2022.
- ^ "@badger: the 1.3 stuff is apparently in iOS 11 and macOS 10.13". 2018-03-09. Retrieved 2018-03-09.
- ^ "[wolfssl] wolfSSL 3.6.6 Released". 2015-08-20. Retrieved 2015-08-24.
- ^ "[wolfssl] wolfSSL 3.13.0 Released". 2017-12-21. Retrieved 2022-01-17.
- ^ "Erlang -- Standards Compliance".
- ^ a b c "Security Enhancements in JDK 8". docs.oracle.com.
- ^ "Bug 663320 - (NSA-Suite-B-TLS) Implement RFC6460 (NSA Suite B profile for TLS)". Mozilla. Retrieved 2014-05-19.
- ^ "Introducing Compliance to Suite B Cryptography". 18 September 2012.
- ^ "Speeds and Feeds › Secure or Compliant, Pick One". Archived from the original on December 27, 2013.
- ^ "Search - Cryptographic Module Validation Program - CSRC". csrc.nist.gov. Archived from the original on 2014-12-26. Retrieved 2014-03-18.
- ^ ""Is botan FIPS 140 certified?" Frequently Asked Questions — Botan". Archived from the original on 2014-11-29. Retrieved 2014-11-16.
- ^ "Search - Cryptographic Module Validation Program - CSRC". csrc.nist.gov. 11 October 2016.
- ^ "cryptlib". 11 October 2013. Archived from the original on 11 October 2013.
- ^ "B.5 Certification". GnuTLS 3.7.7. Retrieved 26 September 2022.
- ^ "Matrix SSL Toolkit" (PDF).
- ^ "Is mbed TLS FIPS certified? - Mbed TLS documentation". Mbed TLS documentation.
- ^ "FIPS Validation - MozillaWiki". wiki.mozilla.org.
- ^ "OpenSSL and FIPS 140-2". Archived from the original on 2013-05-28. Retrieved 2014-11-15.
- ^ "rustls FIPS documentation". Retrieved 2024-08-28.
- ^ "Microsoft FIPS 140 Validated Cryptographic Modules".
- ^ "wolfCrypt FIPS 140-2 Information - wolfSSL Embedded SSL/TLS Library".
- ^ a b c d e f g h i j k l m n o p q r s t u v w x y z aa ab ac ad ae af ag ah RFC 4492. doi:10.17487/RFC4492.
- ^ a b c d e f GOST 28147-89 Cipher Suites for Transport Layer Security (TLS). I-D draft-chudov-cryptopro-cptls-04.
- ^ a b c d e "LibreSSL 2.1.2 released". 2014-12-09. Retrieved 2015-01-20.
- ^ "NSS 3.20 release notes". Mozilla. 2015-08-19. Archived from the original on 2021-12-07. Retrieved 2015-08-20.
- ^ a b c d Mozilla.org. "Bug 518787 - Add GOST crypto algorithm support in NSS". Retrieved 2014-07-01.
- ^ a b c d Mozilla.org. "Bug 608725 - Add Russian GOST cryptoalgorithms to NSS and Thunderbird". Retrieved 2014-07-01.
- ^ a b c d "OpenSSL: CVS Web Interface". Archived from the original on 2013-04-15. Retrieved 2014-11-12.
- ^ a b c d e f g h i j k l m n o Extensions to support GOST in Schannel might be available.[citation needed]
- ^ a b c d "Microsoft Security Advisory 3174644". 14 October 2022.
- ^ a b c "Microsoft Security Bulletin MS14-066 - Critical (Section Update FAQ)". Microsoft. November 11, 2014. Retrieved 11 November 2014.
- ^ a b c Thomlinson, Matt (November 11, 2014). "Hundreds of Millions of Microsoft Customers Now Benefit from Best-in-Class Encryption". Microsoft Security. Retrieved 11 November 2014.
- ^ a b "Update adds new TLS cipher suites and changes cipher suite priorities in Windows 8.1 and Windows Server 2012 R2". support.microsoft.com.
- ^ a b c d e f RFC 5054. doi:10.17487/RFC5054.
- ^ a b c d e f RFC 4279. doi:10.17487/RFC4279.
- ^ a b RFC 5489. doi:10.17487/RFC5489.
- ^ a b RFC 2712. doi:10.17487/RFC2712.
- ^ "RSA BSAFE SSL-J 6.2.4 Release Notes". 2018-09-05. Archived from the original on 2018-09-10.
- ^ a b c "LibreSSL 2.0.4 released". Retrieved 2014-08-04.
- ^ a b c "Bug 405155 - add support for TLS-SRP, rfc5054". Mozilla. Retrieved 2014-01-25.
- ^ a b c d "Bug 306435 - Mozilla browsers should support the new IETF TLS-PSK protocol to help reduce phishing". Mozilla. Retrieved 2014-01-25.
- ^ "Bug 1170510 - Implement NSS server side support for DH_anon". Mozilla. Retrieved 2015-06-03.
- ^ "Bug 236245 - Update ECC/TLS to conform to RFC 4492". Mozilla. Retrieved 2014-06-09.
- ^ "Changes between 0.9.6h and 0.9.7 [31 Dec 2002]". Retrieved 2016-01-29.
- ^ a b "Changes between 0.9.8n and 1.0.0 [29 Mar 2010]". Retrieved 2016-01-29.
- ^ "wolfSSL (Formerly CyaSSL) Release 3.9.0 (03/18/2016)". 2016-03-18. Retrieved 2016-04-05.
- ^ RFC 5280. doi:10.17487/RFC5280.
- ^ RFC 3280. doi:10.17487/RFC3280.
- ^ RFC 2560. doi:10.17487/RFC2560.
- ^ RFC 6698. doi:10.17487/RFC6698.
- ^ RFC 7218. doi:10.17487/RFC7218.
- ^ Laurie, B.; Langley, A.; Kasper, E. (June 2013). Certificate Transparency. IETF. doi:10.17487/RFC6962. ISSN 2070-1721. RFC 6962. Retrieved 2020-08-31.
- ^ "MatrixSSL 3.8.3". Archived from the original on 2017-01-19. Retrieved 2017-01-18.
- ^ "mbed TLS 2.0 defaults implement best practices". Retrieved 2017-01-18.
- ^ "Bug 672600 - Use DNSSEC/DANE chain stapled into TLS handshake in certificate chain validation". Mozilla. Retrieved 2014-06-18.
- ^ "CRL Validation · Issue #3499 · aws/s2n-tls". GitHub. Retrieved 2022-11-01.
- ^ "OCSP digest support for SHA-256 · Issue #2854 · aws/s2n-tls · GitHub". GitHub. Retrieved 2022-11-01.
- ^ "[RFC 6962] s2n Client can Validate Signed Certificate Timestamp TLS Extension · Issue #457 · aws/s2n-tls · GitHub". GitHub. Retrieved 2022-11-01.
- ^ a b "How Certificate Revocation Works". Microsoft TechNet. Microsoft. March 16, 2012. Retrieved July 10, 2013.
- ^ a b
- ^ a b RFC 6655, RFC 7251
- ^ a b c d RFC 6367. doi:10.17487/RFC6367.
- ^ a b RFC 5932. doi:10.17487/RFC5932.
- ^ a b c d RFC 6209. doi:10.17487/RFC6209.
- ^ a b RFC 4162. doi:10.17487/RFC4162.
- ^ a b "Sweet32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN". sweet32.info.
- ^ a b RFC 7905. doi:10.17487/RFC7905.
- ^ a b "Version 1.11.12, 2015-01-02 — Botan". 2015-01-02. Retrieved 2015-01-09.
- ^ "gnutls 3.6.0". 2017-09-21. Retrieved 2018-01-07.
- ^ "gnutls 3.4.12". 2016-05-20. Archived from the original on 2016-10-13. Retrieved 2016-05-29.
- ^ "Java SE DevelopmentK Kit 10 - 10.0.1 Release Notes". 2018-04-17. Retrieved 2024-01-14.
- ^ "JDK 12 Release Notes". Retrieved 2024-01-14.
- ^ a b c d "Changes in 3.8.3". GitHub. Retrieved 2016-06-19.[permanent dead link]
- ^ "PolarSSL 1.3.8 release notes". Archived from the original on 2014-07-14.
- ^ a b "Mbed TLS 2.11.0, 2.7.4 and 2.1.13 released". Retrieved 2018-08-30.
- ^ "Mbed TLS 2.12.0, 2.7.5 and 2.1.14 released". Retrieved 2018-08-30.
- ^ "NSS 3.25 release notes". Mozilla Developer Network. Mozilla. Archived from the original on 2021-12-07. Retrieved 2016-07-01.
- ^ "Bug 940119 - libssl does not support any TLS_ECDHE_*_CAMELLIA_*_GCM cipher suites". Mozilla. Retrieved 2013-11-19.
- ^ "NSS 3.12 is released". Retrieved 2013-11-19.
- ^ "NSS 3.12.3 Release Notes". Mozilla Developer Network. Mozilla. Archived from the original on 2023-04-02. Retrieved 2023-04-01.
- ^ "NSS 3.23 release notes". Mozilla Developer Network. Mozilla. Archived from the original on 2021-04-14. Retrieved 2016-03-09.
- ^ "openssl/CHANGES at OpenSSL_1_0_1-stable · openssl/openssl". GitHub. Retrieved 2015-01-20.
- ^ "OpenSSL 1.1.1 Series Release Notes". www.openssl.org. Archived from the original on 2024-01-16.
- ^ "Cipher Suites in TLS/SSL (Schannel SSP) - Win32 apps". docs.microsoft.com. 14 July 2023.
- ^ a b c "Qualys SSL Labs - Projects / User Agent Capabilities: IE 11 / Win 10 Preview". dev.ssllabs.com. Archived from the original on 2023-07-14.
- ^ RFC 5469
- ^ a b "Sweet32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN".
- ^ "Version 1.11.15, 2015-03-08 — Botan". 2015-03-08. Retrieved 2015-03-11.
- ^ "Java Cryptography Architecture Oracle Providers Documentation". docs.oracle.com.
- ^ "NSS 3.15.3 release notes". Mozilla Developer Network. Mozilla. Archived from the original on 2014-06-05. Retrieved 2014-07-13.
- ^ "MFSA 2013-103: Miscellaneous Network Security Services (NSS) vulnerabilities". Mozilla. Retrieved 2014-07-13.
- ^ a b c "RC4 is now disabled in Microsoft Edge and Internet Explorer 11 - Microsoft Edge Dev BlogMicrosoft Edge Dev Blog". blogs.windows.com. 2016-08-09.
- ^ a b "wolfSSL (Formerly CyaSSL) Release 3.7.0 (10/26/2015)". 2015-10-26. Retrieved 2015-11-19.
- ^ a b c d e RFC 8446
- ^ a b c d e RFC 8422
- ^ a b c RFC 7027
- ^ a b c "Version 1.11.5, 2013-11-10 — Botan". 2013-11-10. Retrieved 2015-01-23.
- ^ "An overview of the new features in GnuTLS 3.5.0". 2016-05-02. Retrieved 2016-12-09.
- ^ "gnutls 3.6.12". 2020-02-01. Retrieved 2021-08-31.
- ^ a b "JDK 13 Early-Access Release Notes". Archived from the original on 2020-04-01. Retrieved 2019-06-20.
- ^ a b "JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)". Retrieved 2024-01-14.
- ^ "LibreSSL 2.5.1 release notes". OpenBSD. 2017-01-31. Retrieved 2017-02-23.
- ^ "MatrixSSL 4.0 changelog". GitHub. Retrieved 2018-09-18.
- ^ "PolarSSL 1.3.3 released". 2013-12-31. Archived from the original on 2014-01-07. Retrieved 2015-01-23.
- ^ "Mbed TLS 2.9.0, 2.7.3 and 2.1.12 released". Retrieved 2018-08-30.
- ^ a b c "PolarSSL 1.3.1 released". 2013-10-15. Archived from the original on 2015-01-23. Retrieved 2015-01-23.
- ^ "Bug 957105 - Add support for curve25519 Key Exchange and UMAC MAC support for TLS". Mozilla. Retrieved 2017-02-23.
- ^ "Bug 1305243 - Support for X448". Mozilla. Retrieved 2022-08-04.
- ^ "Bug 1597057 - Curve448 or named Ed448-Goldilocks support needed (both X448 key exchange and Ed448 signature algorithm )". Mozilla. Retrieved 2022-08-04.
- ^ a b c "Bug 943639 - Support for Brainpool ECC Curve (rfc5639)". Mozilla. Retrieved 2014-01-25.
- ^ "OpenSSL 1.1.0x Release Notes". 25 August 2016. Archived from the original on 18 May 2018. Retrieved 18 May 2018.
- ^ "OpenSSL GitHub Issue #487 Tracker". GitHub. 2 December 2015. Retrieved 18 May 2018.
- ^ "OpenSSL CHANGES". 1 May 2018. Archived from the original on 18 May 2018. Retrieved 18 May 2018.
- ^ "OpenSSL GitHub Issue #5049 Tracker". GitHub. 9 January 2018. Retrieved 18 May 2018.
- ^ "wolfSSL (Formerly CyaSSL) Release 3.4.6 (03/30/2015)". 2015-03-30. Retrieved 2015-11-19.
- ^ "wolfSSL Release 4.4.0 (04/22/2020)". 2020-04-22. Retrieved 2022-10-18.
- ^ "Release Note: Weak Named Curves in TLS, CertPath, and Signed JAR Disabled by Default". JDK Bug System (JBS). Retrieved 25 December 2024.
- ^ "Release Note: Removal of Legacy Elliptic Curves". JDK Bug System (JBS). Retrieved 25 December 2024.
- ^ a b Negotiation of arbitrary curves has been shown to be insecure for certain curve sizes Mavrogiannopoulos, Nikos and Vercautern, Frederik and Velichkov, Vesselin and Preneel, Bart (2012). "A cross-protocol attack on the TLS protocol" (PDF). Proceedings of the 2012 ACM conference on Computer and communications security. Association for Computing Machinery. pp. 62–72. doi:10.1145/2382196.2382206. ISBN 978-1-4503-1651-4.
{{cite conference}}: CS1 maint: multiple names: authors list (link) - ^ "SHA2 and Windows". Retrieved 2024-12-25.
- ^ RFC 3749
- ^ RFC 5746
- ^ a b c RFC 6066
- ^ RFC 7301
- ^ RFC 6091
- ^ RFC 4680
- ^ RFC 5077. doi:10.17487/RFC5077.
- ^ RFC 5705. doi:10.17487/RFC5705.
- ^ RFC 7507. doi:10.17487/RFC7507.
- ^ RFC 7627
- ^ RFC 7685
- ^ RFC 7250
- ^ "Version 1.11.16, 2015-03-29 — Botan". 2016-03-29. Retrieved 2016-09-08.
- ^ "Version 1.11.10, 2014-12-10 — Botan". 2014-12-10. Retrieved 2014-12-14.
- ^ a b "Version 1.11.26, 2016-01-04 — Botan". 2016-01-04. Retrieved 2016-02-25.
- ^ Present, but disabled by default due to lack of use by any implementation.
- ^ "gnutls 3.2.0". Archived from the original on 2016-01-31. Retrieved 2015-01-26.
- ^ Mavrogiannopoulos, Nikos (August 21, 2017). "[gnutls-help] GnuTLS 3.6.0 released".
- ^ "gnutls 3.4.4". Archived from the original on 2017-07-17. Retrieved 2015-08-25.
- ^ "%DUMBFW priority keyword". Retrieved 2017-04-30.
- ^ "gnutls 3.6.6". 2019-01-25. Retrieved 2019-09-01.
- ^ "LibreSSL 2.1.3 released". 2015-01-22. Retrieved 2015-01-22.
- ^ "LibreSSL 2.1.4 released". 2015-03-04. Retrieved 2015-03-04.
- ^ "MatrixSSL - News". 2014-12-04. Archived from the original on 2015-02-14. Retrieved 2015-01-26.
- ^ "Download overview - PolarSSL". 2014-04-11. Archived from the original on 2015-02-09. Retrieved 2015-01-26.
- ^ a b c "mbed TLS 1.3.10 released". 2015-02-08. Archived from the original on 2015-02-09. Retrieved 2015-02-09.
- ^ a b "NSS 3.15.5 release notes". Mozilla Developer Network. Mozilla. Archived from the original on January 26, 2015. Retrieved 2015-01-26.
- ^ "Bug 961416 - Support RFC6091 - Using OpenPGP Keys for Transport Layer Security Authentication (TLS1.2)". Mozilla. Retrieved 2014-06-18.
- ^ "Bug 972145 - Implement the encrypt-then-MAC TLS extension". Mozilla. Retrieved 2014-11-06.
- ^ "NSS 3.17.1 release notes". Archived from the original on 2019-04-19. Retrieved 2014-10-17.
- ^ "NSS 3.21 release notes". Archived from the original on 2021-12-07. Retrieved 2015-11-14.
- ^ "OpenSSL Security Advisory [15 Oct 2014]". 2014-10-15.
- ^ "Major changes between OpenSSL 1.0.1f and OpenSSL 1.0.1g [7 Apr 2014]". 2014-04-07. Archived from the original on 2015-01-20. Retrieved 2015-02-10.
- ^ "OpenSSL Announces Final Release of OpenSSL 3.2.0". 2023-11-23. Retrieved 2024-10-11.
- ^ rustls does not implement earlier versions that would warrant protection against insecure downgrade
- ^ a b c d "Microsoft Security Bulletin MS15-121". March 2023. Retrieved 2024-04-28.
- ^ a b "What's New in TLS/SSL (Schannel SSP)". 31 August 2016. Retrieved 2024-04-28.
- ^ "wolfSSL Version 4.2.0 is Now Available!". 22 October 2019. Retrieved 2021-08-13.
- ^ "wolfSSL supports Raw Public Keys". August 2023. Retrieved 2024-10-25.
- ^ "Version 1.11.31, 2015-08-30 — Botan". 2016-08-30. Retrieved 2016-09-08.
- ^ "Trusted Platform Module (TPM) — Botan".
- ^ "JEP 164: Leverage CPU Instructions for AES Cryptography". openjdk.org.
- ^ "RSA SecurID PASSCODE Request". sso.rsasecurity.com.
- ^ "Comparison of BSAFE TLS libraries: Micro Edition Suite vs SSL-J | Dell Malaysia".
- ^ Mavrogiannopoulos, Nikos (October 9, 2016). "[gnutls-devel] gnutls 3.5.5".
- ^ "Trusted Platform Module (GnuTLS 3.8.4)".
- ^ "Java SSL provider with AES-NI support". stackoverflow.com.
- ^ "PolarSSL 1.3.3 released". 2013-12-31. Archived from the original on 2014-01-07. Retrieved 2014-01-07.
We've incorporated support for AES-NI in our AES and GCM modules.
- ^ a b "NXP/Plug-and-trust". GitHub.
- ^ "ARMmbed/Mbed-os-atecc608a". GitHub.
- ^ Normally NSS's libssl performs all operations via the PKCS#11 interface, either to hardware or software tokens
- ^ "Bug 706024 - AES-NI enhancements to NSS on Sandy Bridge systems". Retrieved 2013-09-28.
- ^ "Bug 479744 - RFE : VIA Padlock ACE support (hardware RNG, AES, SHA1 and SHA256)". Retrieved 2014-04-11.
- ^ "Подключаем Рутокен ЭЦП к OpenSSL" (in Russian). 16 December 2011.
- ^ "Поддержка Рутокен ЭЦП в OpenSSL (Страница 1) — Рутокен и Open Source — Форум Рутокен" (in Russian).
- ^ "OpenSSL ГОСТ" (in Russian). Archived from the original on 2018-06-23.
- ^ "git.openssl.org Git - openssl.git/commitdiff". git.openssl.org.
- ^ "Tpm2-software/Tpm2-openssl". GitHub.
- ^ "Provider - OpenSSL Documentation".
- ^ "STSW-STSA110-SSL - STSAFE-A integration within OpenSSL security stack". STMicroelectronics.
- ^ SecECKey.c on GitHub
- ^ "Crypto Officer Role Guide for FIPS 140-2 Compliance OS X Mountain Lion v10.8" (PDF). Apple Inc. 2013.
- ^ "CAAM support in wolfSSL". 10 March 2020.
- ^ "wolfTPM Portable TPM 2.0 Library".
- ^ "Announcing wolfSSL TPM support for the Espressif ESP32". 20 June 2024.
- ^ "WolfSSL SSL/TLS Support for NXP SE050 – wolfSSL". 22 February 2024.
- ^ "WolfSSL support for the ATECC608 Crypto Coprocessor – wolfSSL". 13 October 2021.
- ^ "WolfSSL support for STSAFE-A100 crypto coprocessor – wolfSSL". 20 September 2018.
- ^ "Support for MAXQ1065 in wolfSSL – wolfSSL". 29 November 2022.
- ^ "LibreSSL 2.2.1 Released". 2015-07-08. Retrieved 2016-01-30.
- ^ "ktls integration for rustls". GitHub. Retrieved 2024-08-29.
- ^ "wolfProvider". 2021-11-10. Retrieved 2022-01-17.
- ^ a b The PKCS #11 URI Scheme. doi:10.17487/RFC7512. RFC 7512.
- ^ "libp11: PKCS#11 wrapper library". 19 January 2018 – via GitHub.
- ^ "Windows CNG bridge for rustls". GitHub. Retrieved 2024-08-29.
- ^ On the fly replaceable/augmentable.
- ^ "Nss compat ossl - Fedora Project Wiki". fedoraproject.org.
- ^ "rustls-openssl compatibility layer". GitHub. Retrieved 2024-08-29.
- ^ a b "NSPR". Mozilla Developer Network.
- ^ For Unix/Linux it uses /dev/urandom if available, for Windows it uses CAPI. For other platforms it gets data from clock, and tries to open system files. NSS has a set of platform dependent functions it uses to determine randomness.
Comparison of TLS implementations
View on Grokipediafrom Grokipedia
Transport Layer Security (TLS) implementations are software libraries and frameworks that enable secure data transmission over networks by providing cryptographic functions for encryption, authentication, and integrity protection, adhering to standards defined by the Internet Engineering Task Force (IETF). Comparisons of these implementations assess critical dimensions including support for TLS protocol versions (from 1.0 to 1.3), cryptographic algorithms and cipher suites, performance metrics such as handshake latency and throughput under varying loads, security attributes like vulnerability history and FIPS 140 compliance, as well as factors like code footprint for embedded systems and licensing models.[1][2] Prominent open-source implementations include OpenSSL, BoringSSL, GnuTLS, mbed TLS, wolfSSL, and LibreSSL, each tailored to different use cases from high-performance servers to resource-constrained devices.[1][3]
Security remains a primary focus in these comparisons, as TLS libraries have historically been targets for exploits like Heartbleed in OpenSSL (2014), which exposed memory contents and affected millions of systems, prompting forks such as BoringSSL for enhanced auditing and LibreSSL for code simplification.[2] Modern evaluations highlight differences in handling protocol downgrades, certificate validation, and post-quantum cryptography readiness; for instance, wolfSSL offers lightweight FIPS-certified modules suitable for IoT, while mbed TLS provides lightweight alternatives for resource-constrained devices, and OpenSSL 3.x introduces stricter API controls but has faced criticism for compatibility regressions.[4][5][6] As of 2025, libraries like BoringSSL prioritize bleeding-edge features with frequent updates from Google, though this can lead to API instability, whereas GnuTLS emphasizes POSIX compliance and LGPL licensing for broader integration.[1][2]
Performance benchmarks reveal significant variances, particularly in multi-threaded environments; as of 2024 benchmarks on AWS r8g.16xlarge hardware, AWS-LC (a fork of BoringSSL) achieves up to 183,000 end-to-end connections per second with TLS resumption at 64 threads, outperforming OpenSSL 3.0.14's 3,700 under similar conditions due to optimized locking mechanisms.[2] wolfSSL excels in embedded scenarios with faster elliptic curve operations compared to OpenSSL in TLS 1.3 handshakes, as shown in 2018 benchmarks.[7] In contrast, rustls (a Rust-based library) offers memory safety guarantees but limited feature parity, such as partial QUIC support.[1] Feature support also differs: most contemporary libraries fully implement TLS 1.3 for reduced latency (one round-trip handshakes), ALPN for protocol negotiation, and extensions like 0-RTT resumption, though adoption of QUIC (RFC 9000) varies, with BoringSSL and wolfSSL leading in experimental integrations.[2]
These comparisons guide developers in selecting implementations based on application needs, such as balancing security audits (e.g., NSS in Mozilla products) with deployment overhead, and underscore ongoing evolution toward quantum-resistant algorithms amid threats from advances in computing power, with varying PQC support across libraries as of 2025.[8][5] As TLS underpins HTTPS, email security (SMTPS), and VPNs, rigorous evaluations ensure robust protection against eavesdropping and man-in-the-middle attacks in an increasingly connected ecosystem.[3]
OpenSSL, since version 1.1.1 (2018), disables TLS 1.0 and 1.1 by default via its security level settings (SECLEVEL=2), aligning with IETF deprecation timelines, though users can enable them using functions like SSL_CTX_set_min_proto_version for backward compatibility in controlled environments.[26][27] BoringSSL, a Google-maintained OpenSSL fork, similarly requires explicit enabling of pre-TLS 1.2 versions through API flags, emphasizing security by prioritizing modern protocols in products like Chrome. GnuTLS, starting with version 3.8 (2023), removed SSL 3.0 from default compilation to reduce attack surface, responding to its obsolescence, while retaining configurable support for TLS 1.0 and 1.1 until broader ecosystem migration; version 3.7 (2020) began stricter handling of legacy protocols.[29] NSS, used in Mozilla products, supports legacy versions for flexibility but disables TLS 1.0/1.1 by default in Firefox since version 78 (2020), enforcing TLS 1.2 as the minimum to comply with deprecation recommendations.[30] mbed TLS 3.x series explicitly dropped support for SSL 3.0, TLS 1.0, and 1.1 to streamline for embedded systems, focusing solely on TLS 1.2 and 1.3 for enhanced security and reduced code footprint.[32]
TLS 1.3 mandates forward secrecy across all compliant implementations by eliminating static key exchanges (e.g., RSA key transport) and requiring ephemeral Diffie-Hellman (DHE/ECDHE) or equivalent for every session, ensuring that compromise of long-term keys does not decrypt past traffic; this is uniformly enforced in OpenSSL, BoringSSL, GnuTLS, NSS, mbed TLS, and wolfSSL as part of RFC 8446 compliance.[9]
GnuTLS provides the most comprehensive out-of-the-box suite, including Brainpool variants, while mbedTLS prioritizes lightweight support suitable for resource-constrained environments, often enabling only essential curves by default.[61]
Security considerations include handling self-signed certificates, which most implementations reject by default unless explicitly trusted as roots, to avoid unauthorized endpoints. Extended Validation (EV) certificates, which undergo rigorous identity checks per CA/Browser Forum guidelines, see declining support post-2019 as browsers like Firefox 70 and Chrome 77 removed distinctive UI indicators (e.g., green bars), treating them like domain-validated certificates since users rarely noticed or acted on the distinction. This shift prioritizes usability while maintaining backend validation, though EV issuance continues for compliance.[70]
This table summarizes certification status for major implementations as of November 2025, highlighting gaps like mbed TLS's incomplete FIPS validation and LibreSSL's lack of support.[71][6][72]
Sizes represent compiled library binaries with basic TLS support and exclude tests or full toolchains; actual footprints depend on configuration.[133][134]
Introduction
Overview
Transport Layer Security (TLS) is a cryptographic protocol that provides communications privacy and data integrity between two communicating applications, such as a web browser and a server, over an unreliable network like the Internet.[9] It ensures confidentiality by encrypting the transmitted data, integrity by detecting any modifications, and authentication to verify the identity of the communicating parties, typically the server and optionally the client.[9] TLS evolved from the Secure Sockets Layer (SSL) protocol, originally developed by Netscape Communications to secure HTTP traffic for early web browsers.[10] The history of TLS traces back to the mid-1990s when Netscape introduced SSL 2.0 in 1995 and SSL 3.0 in 1996 to address growing needs for secure online transactions amid the expanding Internet.[10] Recognizing the proprietary nature of SSL, the Internet Engineering Task Force (IETF) formed a working group in 1996 to standardize it, resulting in TLS 1.0 as an upgrade to SSL 3.0, published as RFC 2246 in 1999.[11] Subsequent iterations improved security and efficiency: TLS 1.1 (RFC 4346, 2006) addressed vulnerabilities like CBC attacks, TLS 1.2 (RFC 5246, 2008) added support for advanced cipher suites, and TLS 1.3 (RFC 8446, 2018) streamlined the handshake for better performance and removed obsolete cryptographic options.[9] Major open-source TLS implementations include several widely adopted libraries, each tailored to specific environments. OpenSSL is a versatile toolkit implementing SSL and TLS protocols, commonly used in general-purpose servers, web applications, and cryptographic operations across various platforms.[12] BoringSSL, a fork of OpenSSL maintained by Google, powers secure connections in Chrome, Android, and Google services, prioritizing integration with Google's ecosystem over broad API stability.[13] Network Security Services (NSS) from Mozilla provides libraries for security-enabled applications, primarily supporting TLS in Firefox and other Mozilla products like Thunderbird.[14] GnuTLS, part of the GNU project, serves as a secure communications backend for Linux distributions and applications requiring TLS, DTLS, and certificate handling.[15] mbed TLS, developed by Arm, offers a lightweight implementation optimized for resource-constrained embedded systems and IoT devices.[16] LibreSSL, a fork of OpenSSL, emphasizes code auditing, portability, and removal of deprecated features for improved security.[17] wolfSSL provides a lightweight, embeddable library with strong support for FIPS compliance and real-time operating systems.[18] This comparison evaluates these implementations across key dimensions, including security (e.g., vulnerability history and cryptographic robustness), performance (e.g., handshake latency and throughput), compatibility (e.g., protocol version and extension support), and maintainability (e.g., code quality and update frequency), to guide developers in selecting appropriate libraries for secure deployments.[3]Comparison Criteria
The comparison of TLS implementations relies on standardized criteria to ensure objective evaluation across diverse libraries such as OpenSSL, BoringSSL, and GnuTLS. These criteria are grouped into key categories: security, which assesses vulnerability history and resistance to known exploits like those documented in CVE databases; compatibility, evaluating support for protocol versions and interoperability with clients; performance, measuring metrics such as handshake latency and throughput under load; and ecosystem integration, examining ease of embedding in applications and support for platform-specific features.[19][1][20] Data for these evaluations is drawn from authoritative sources to maintain verifiability and recency. Official documentation from library maintainers provides baseline feature details, while RFCs such as RFC 8446 define core TLS 1.3 requirements for protocol fidelity. Third-party audits from independent security firms offer insights into vulnerability patching timelines. Tools like Qualys SSL Labs deliver quantitative scoring through automated scans of server configurations using the libraries, assigning grades (A-F) based on configuration strength, cipher suite robustness, and certificate chain validation.[2] Comparisons are typically presented in tabular formats for clarity, with implementations (e.g., rows or columns) juxtaposed against criteria (e.g., opposite rows or columns) to highlight supported features, versions, or scores. For instance, a table might list protocol versions in rows and libraries in columns, using checkmarks for full support, partial indicators for experimental features, and footnotes for deprecated elements like MD5 hashing. This approach facilitates quick identification of trade-offs, such as BoringSSL's streamlined cipher support versus OpenSSL's broader but potentially riskier options. Notes accompany entries to contextualize variations, such as conditional support dependent on build flags.[1][2] Despite these methods, comparisons face inherent limitations that must be acknowledged for balanced interpretation. Open-source implementations like LibreSSL often benefit from community scrutiny but may lag in proprietary optimizations, introducing biases toward feature breadth over specialized performance tuning. The dynamic landscape of TLS, including post-2023 integrations of quantum-resistant algorithms like those standardized by NIST (e.g., ML-KEM), means evaluations can quickly outdated without ongoing updates, emphasizing the need for timestamped assessments.[21][22][23]Protocol Support
TLS/SSL Version Support
The Transport Layer Security (TLS) protocol and its predecessor, Secure Sockets Layer (SSL), have evolved through several versions to address security vulnerabilities and improve cryptographic strength. SSL 2.0, released in 1995, and SSL 3.0, released in 1996, are obsolete due to severe flaws such as weak key exchanges and susceptibility to attacks like POODLE; SSL 3.0 was formally deprecated by the IETF in RFC 7568 (2015), mandating that implementations must not negotiate it and should terminate connections attempting to do so.[24] TLS 1.0 (RFC 2246, 1999) and TLS 1.1 (RFC 4346, 2006) introduced improvements but remain deprecated under RFC 8996 (2021), which classifies them as Historic due to their reliance on vulnerable algorithms like SHA-1, lack of support for authenticated encryption, and exposure to downgrade attacks; implementations are required to reject negotiations of these versions with a protocol_version alert.[25] TLS 1.2 (RFC 5246, 2008) is now considered legacy but widely used, while TLS 1.3 (RFC 8446, 2018) is the current standard, emphasizing streamlined handshakes and mandatory forward secrecy.[9] Major TLS implementations vary in their support for these versions, often disabling deprecated ones by default to mitigate risks while allowing explicit enablement for legacy compatibility. The following table summarizes support across key open-source libraries, focusing on whether versions are compiled in, enabled by default, or require configuration:| Implementation | SSL 3.0 | TLS 1.0 | TLS 1.1 | TLS 1.2 | TLS 1.3 | Default Minimum Version |
|---|---|---|---|---|---|---|
| OpenSSL (3.x) | No | No (explicit enable) | No (explicit enable) | Yes | Yes | TLS 1.2[26][27] |
| BoringSSL | No | No (explicit enable required) | No (explicit enable required) | Yes | Yes | TLS 1.2 |
| GnuTLS (3.8.x) | No (not compiled by default) | Yes (configurable) | Yes (configurable) | Yes | Yes | TLS 1.2 (configurable via priority strings)[28][29] |
| NSS (3.100+) | No | Yes (configurable, disabled in modern apps like Firefox) | Yes (configurable, disabled in modern apps) | Yes | Yes | TLS 1.2 (in Firefox; configurable)[30][31] |
| mbed TLS (3.x) | No | No | No | Yes | Yes | TLS 1.2 (support for older versions removed)[32][33] |
| wolfSSL | No | No (explicit enable required) | No (explicit enable required) | Yes | Yes | TLS 1.2[34] |
Extension and Feature Support
TLS protocol extensions provide optional enhancements to the core handshake, enabling features such as virtual hosting, revocation checking, and application-layer protocol negotiation. Server Name Indication (SNI), defined in RFC 6066, allows clients to specify the target hostname during the handshake, supporting multiple domains on a single IP address; this extension is universally supported across major implementations, including OpenSSL (since version 0.9.8j), BoringSSL, NSS, mbed TLS (via configuration), GnuTLS, and wolfSSL. OCSP Stapling, also from RFC 6066, permits servers to attach Online Certificate Status Protocol responses to the handshake, reducing client latency and privacy risks associated with direct OCSP queries; support varies, with full implementation in OpenSSL (via SSL_CTX_set_tlsext_status_cb since 1.0.0), BoringSSL, NSS (integrated in Firefox for browser contexts), GnuTLS (since 3.1.10), and wolfSSL (including multi-stapling per RFC 6961), but absent in mbed TLS due to resource constraints in embedded environments. Session Tickets, outlined in RFC 5077, facilitate stateless session resumption by encrypting session state in tickets issued by the server; all listed implementations provide client-side support, with server-side capabilities in OpenSSL (since 0.9.8f), BoringSSL, NSS, mbed TLS (configurable via MBEDTLS_SSL_SESSION_TICKETS), GnuTLS, and wolfSSL. Application-Layer Protocol Negotiation (ALPN), per RFC 7301, enables protocol selection (e.g., HTTP/2) within the TLS handshake to avoid additional round trips; it is supported comprehensively in OpenSSL (since 1.0.2), BoringSSL, NSS, mbed TLS, GnuTLS, and wolfSSL. Implementation variances arise from design priorities, such as resource optimization in embedded systems or integration with specific ecosystems. For instance, mbed TLS prioritizes lightweight operation, offering partial or configurable support for extensions like SNI and ALPN but omitting OCSP Stapling to minimize footprint.[35] In contrast, NSS, tailored for browser use in Firefox, historically excelled in features like the deprecated False Start extension (removed post-2013 due to vulnerabilities), which allowed early data transmission but is no longer recommended.[36] Post-TLS 1.3 features address evolving privacy and performance needs, building on the protocol's streamlined handshake. Encrypted Client Hello (ECH), an IETF standard (draft-ietf-tls-esni-25 as of 2025, approved for publication as RFC), encrypts sensitive ClientHello fields like SNI to mitigate network surveillance; experimental support exists in OpenSSL via third-party integrations, full client-side in NSS (Firefox since 2023), full in BoringSSL and wolfSSL, while GnuTLS and mbed TLS lag with partial or planned implementations.[37][38][39] Zero-Round-Trip Time (0-RTT) resumption in TLS 1.3 (RFC 8446) enables immediate data transmission on resumption but introduces replay attack risks; mitigations include server-side anti-replay windows and application-level idempotency. Support is mature in OpenSSL (1.1.1+), BoringSSL, NSS, GnuTLS (3.7+), and wolfSSL, with mbed TLS enabling it optionally in version 3.0+ configurations.[9][40]| Implementation | SNI (RFC 6066) | OCSP Stapling (RFC 6066) | Session Tickets (RFC 5077) | ALPN (RFC 7301) | ECH (Draft) | 0-RTT (TLS 1.3) |
|---|---|---|---|---|---|---|
| OpenSSL | Full (0.9.8j+) | Full (1.0.0+) | Full (0.9.8f+) | Full (1.0.2+) | Experimental | Full (1.1.1+) |
| BoringSSL | Full | Full | Full | Full | Full | Full |
| NSS | Full | Full | Full | Full | Full (Client) | Full |
| mbed TLS | Full (Config.) | Absent | Full (Config.) | Full | Planned | Optional (3.0+) |
| GnuTLS | Full (2.12+) | Full (3.1.10+) | Full | Full (3.2+) | Partial | Full (3.7+) |
| wolfSSL | Full | Full (RFC 6961) | Full | Full | Full | Full |
Cryptographic Mechanisms
Key Exchange Algorithms
Key exchange algorithms in TLS are responsible for securely establishing a shared secret between client and server during the handshake, enabling subsequent symmetric encryption. Certificate-based methods rely on public key infrastructure (PKI) for authentication, while alternatives like pre-shared keys avoid certificates entirely. Modern TLS versions, particularly TLS 1.3, emphasize ephemeral methods for perfect forward secrecy (PFS), which ensures that session keys remain secure even if the long-term private key is compromised later.[41] Certificate-based key exchanges include static RSA using PKCS#1 v1.5 padding, which has been deprecated due to vulnerabilities like padding oracle attacks and lack of PFS; it directly encrypts the pre-master secret with the server's public key. In contrast, ephemeral Diffie-Hellman (DHE) and elliptic curve Diffie-Hellman (ECDHE) generate temporary keys for each session, providing PFS and resistance to long-term key compromise. ECDHE is preferred over DHE for its computational efficiency and smaller key sizes, using elliptic curves like NIST P-256. All major implementations support ECDHE and DHE for PFS, with minimum RSA key sizes of 2048 bits mandated by certificate authorities to meet security levels equivalent to 112 bits of symmetric strength.[42][43] These algorithms map to specific cipher suites, such as TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, where ECDHE handles key exchange, RSA authenticates the server, AES-256-GCM provides confidentiality, and SHA-384 ensures integrity. Implementations differ in defaults: BoringSSL, a fork of OpenSSL optimized for performance, prioritizes ECDHE in its cipher suite ordering to favor PFS-enabled suites by default. GnuTLS offers broader support for legacy DHE groups, including finite-field Diffie-Hellman parameters like 1024-bit (though not recommended) and standardized FFDHE groups up to 8192 bits, enabling compatibility with older systems.[44][45] Alternative methods include pre-shared key (PSK) exchanges, which use symmetric keys provisioned out-of-band for authentication and key derivation, suitable for IoT or closed networks without PKI. Secure Remote Password (SRP) extends PSK with password-based authentication to prevent offline dictionary attacks. OpenSSL and GnuTLS fully support both PSK and SRP, while mbed TLS omits SRP and limits PSK to specific configurations; NSS and wolfSSL support PSK but not SRP natively.[46] Post-quantum candidates address threats from quantum computers capable of breaking classical schemes like RSA and ECDHE via Shor's algorithm. Kyber, now standardized as ML-KEM in NIST FIPS 203 (2024), a lattice-based key encapsulation mechanism (KEM), has been integrated in OpenSSL 3.5+ for hybrid modes like X25519+ML-KEM in TLS 1.3, combining classical and post-quantum security. BoringSSL and wolfSSL also support hybrid ML-KEM key exchange in production builds as of 2025, while GnuTLS offers experimental integrations.[23][47][48]| Implementation | RSA (PKCS#1 v1.5) | ECDHE (PFS) | DHE (PFS) | PSK | SRP | Kyber (PQ) |
|---|---|---|---|---|---|---|
| OpenSSL | Yes (legacy) | Yes | Yes | Yes | Yes | Integrated (3.5+) |
| BoringSSL | Yes (legacy) | Yes (prioritized) | Yes | Yes | No | Yes (hybrid) |
| GnuTLS | Yes (legacy) | Yes | Yes (legacy groups) | Yes | Yes | Experimental |
| mbed TLS | Yes (legacy) | Yes | Yes | Limited | No | No |
| NSS | Yes (legacy) | Yes | Yes | Yes | No | No |
| wolfSSL | Yes (legacy) | Yes | Yes | Yes | Yes | Yes |
Symmetric Encryption Algorithms
Symmetric encryption algorithms in TLS are responsible for protecting the confidentiality of application data exchanged after the handshake, using symmetric keys derived from the key exchange process. These algorithms operate in modes that provide bulk encryption, with modern implementations prioritizing Authenticated Encryption with Associated Data (AEAD) modes to combine encryption and integrity protection in a single primitive. For TLS 1.2 and later, AEAD ciphers are the standard for symmetric encryption. The Advanced Encryption Standard in Galois/Counter Mode (AES-GCM) with 128-bit or 256-bit keys is widely supported, offering high security and efficiency on hardware-accelerated platforms. AES-128-GCM and AES-256-GCM cipher suites, such as TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, are enabled by default in all major implementations. Additionally, ChaCha20-Poly1305, introduced in RFC 7905, provides an alternative AEAD cipher suite like TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, which is also universally supported and preferred in environments lacking AES hardware acceleration. Legacy stream and block ciphers persist in some implementations for backward compatibility but are deprecated due to vulnerabilities. RC4, a stream cipher, has been disabled or removed in modern TLS libraries since 2015, following revelations of biases exploitable in TLS contexts, rendering it unsuitable for use. Triple DES (3DES) in Cipher Block Chaining (CBC) mode, with an effective 112-bit key strength, is similarly weak against modern attacks like Sweet32 and is disabled by default in recent versions, though still compilable in some. AES in CBC mode, such as AES-128-CBC or AES-256-CBC, offers better security than predecessors but suffers from padding oracle vulnerabilities if not implemented with encrypt-then-MAC, leading to its deprecation in favor of AEAD modes. NIST guidelines recommend AES-GCM variants for TLS deployments, designating AES-256-GCM as FIPS 140-approved for high-security environments while prohibiting RC4, 3DES, and CBC modes in new systems. Implementation defaults align with these, as seen in OpenSSL 3.0 and later, which disable CBC and legacy ciphers by default under the new provider model to enforce secure configurations. Performance considerations favor ChaCha20-Poly1305 on resource-constrained or non-x86 devices without AES-NI instructions, where it achieves comparable throughput to AES-GCM without specialized hardware, reducing latency in mobile or embedded scenarios.| Implementation | AES-128-GCM | AES-256-GCM | ChaCha20-Poly1305 | AES-CBC | 3DES-CBC | RC4 |
|---|---|---|---|---|---|---|
| OpenSSL 3.x | Enabled | Enabled | Enabled | Disabled by default | Disabled by default | Removed [49][50] |
| BoringSSL | Enabled | Enabled | Enabled | Supported, not preferred | Disabled | Removed |
| NSS 3.90+ | Enabled | Enabled | Enabled | Disabled by default | Disabled | Disabled [51] |
| GnuTLS 3.8+ | Enabled | Enabled | Enabled | Supported, configurable | Disabled by default | Deprecated, disabled [52] |
| mbed TLS 3.x | Enabled | Enabled | Enabled | Supported, configurable | Removed | Not supported [53] |
Message Authentication Algorithms
Message authentication in TLS ensures the integrity and authenticity of transmitted data by verifying that messages have not been altered or forged during transit. In TLS versions prior to 1.3, this is typically achieved using Hash-based Message Authentication Codes (HMAC) applied to the plaintext after encryption, while TLS 1.3 integrates authentication directly into Authenticated Encryption with Associated Data (AEAD) modes for improved efficiency and security. These mechanisms prevent tampering attacks, such as those exploiting padding oracles, by producing a tag that the receiver validates against the received data.[54] For TLS 1.2, HMAC-based authentication relies on secure hash functions like SHA-256 and SHA-384, where the HMAC is computed over the encrypted message and associated data using keys derived from the master secret. Cipher suites such as TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 employ HMAC-SHA-384 to provide 192-bit security strength against collision attacks. In TLS 1.3, while AEAD handles primary authentication, HMAC remains foundational through the HKDF (HMAC-based Key Derivation Function) for key expansion and derivation from the handshake secrets, ensuring consistent security across traffic protection keys. HKDF-Extract uses HMAC to pseudorandomly derive intermediate keys, followed by HKDF-Expand for final key material, replacing the less secure PRF from earlier versions.[54][55][9] AEAD constructions streamline authentication by combining encryption and integrity protection in a single operation. AES-GCM (Galois/Counter Mode) generates an authentication tag via the GHASH polynomial hash over the ciphertext, additional authenticated data, and a unique tag, providing 128-bit or higher security when paired with SHA-256 or SHA-384 in cipher suites like TLS_AES_128_GCM_SHA256. Similarly, the ChaCha20-Poly1305 AEAD uses the Poly1305 one-time authenticator—a 128-bit MAC based on polynomial evaluation over the message—to verify integrity, offering resistance to timing attacks and suitability for software implementations without hardware acceleration. These are mandatory in TLS 1.3 and preferred in 1.2 for their efficiency.[9] Older algorithms like MD5 and SHA-1 for HMAC have been deprecated due to cryptographic weaknesses exposed by attacks starting around 2011, including practical collisions for SHA-1 and padding vulnerabilities. The POODLE attack (CVE-2014-3566), disclosed in 2014, exploited fallback to SSL 3.0—which used a combined MD5/SHA-1 MAC—allowing attackers to decrypt sensitive data by forcing protocol downgrades and manipulating padding. As a result, modern TLS deployments disable these hashes entirely, with RFC 9155 formally deprecating MD5 and SHA-1 in TLS 1.2 signatures and implicitly in legacy MACs to mitigate ongoing risks. TLS implementations differ in their support for these algorithms, balancing security, performance, and resource constraints. Major libraries like OpenSSL, BoringSSL, GnuTLS, NSS, and mbed TLS all support core HMAC-SHA-256/384 and AEAD options, but vary in advanced features like SHA-3 integration. For instance, NSS includes FIPS-validated SHA-3 support since version 3.36 in 2018, enabling HMAC-SHA-3 in compliant modes for enhanced post-quantum readiness. In contrast, mbed TLS prioritizes embedded systems by limiting TLS authentication to the SHA-2 family, avoiding SHA-3 due to computational overhead despite basic hash support. These authentication algorithms are often paired with symmetric ciphers in cipher suites to ensure comprehensive protection.| Implementation | HMAC-SHA-256 | HMAC-SHA-384 | HMAC-SHA-3 | AES-GCM Auth Tag | ChaCha20-Poly1305 | Notes |
|---|---|---|---|---|---|---|
| OpenSSL | Yes | Yes | Yes (3.0+) | Yes | Yes | Full AEAD support; SHA-3 via libgcrypt or internal. |
| BoringSSL | Yes | Yes | No | Yes | Yes | Optimized for Google services; prioritizes performance over legacy. |
| GnuTLS | Yes | Yes | Experimental | Yes | Yes | Supports HMAC variants; SHA-3 via external plugins.[56] |
| NSS | Yes | Yes | Yes (3.36+) | Yes | Yes | FIPS 140-2/3 validated; SHA-3 for high-security environments. |
| mbed TLS | Yes | Yes | No (hash only) | Yes | Yes | SHA-2 focused for IoT; no SHA-3 in TLS due to constraints. |
Elliptic Curve Cryptography Support
Elliptic Curve Cryptography (ECC) plays a central role in modern TLS implementations for key exchange via Elliptic Curve Diffie-Hellman (ECDH) and digital signatures via Elliptic Curve Digital Signature Algorithm (ECDSA). TLS standards define specific curves to ensure interoperability and security, with implementations varying in their support for these primitives. The primary curves are those specified in RFC 8422 for TLS 1.2 and earlier, which include the NIST-approved P-256, P-384, and P-521 curves, providing security levels of 128, 192, and 256 bits, respectively.[57][58] For TLS 1.3, RFC 8446 mandates support for X25519 and X448 from the Curve25519 family, offering 128-bit and 224-bit security levels, respectively, as integrated key exchange mechanisms.[9][58] Several older curves, such as sect163k1 and other binary field curves from earlier standards, have been deprecated due to insufficient security margins and lack of widespread adoption.[57] Brainpool curves, defined in RFC 5639 and initially supported in TLS 1.2 via RFC 7027, faced limited adoption and were excluded from TLS 1.3 in its original specification owing to low usage; however, RFC 8734 later enabled their use in TLS 1.3 for scenarios requiring them, such as in European standards.[59] In OpenSSL versions prior to 3.2, Brainpool curves were supported for TLS 1.2 but not TLS 1.3, reflecting caution around historical concerns with elliptic curve generation tied to flawed random number generators like Dual_EC_DRBG, though Brainpool itself stems from independent BSI specifications. Other implementations, like GnuTLS, have maintained fuller support for Brainpool across versions. As quantum computing advances threaten classical ECC, TLS implementations are exploring post-quantum readiness through hybrid modes that combine traditional ECDH with quantum-resistant algorithms. For instance, support in BoringSSL enables hybrid key exchanges pairing ECDHE (using curves like X25519) with ML-KEM (Kyber), a lattice-based key encapsulation mechanism standardized in NIST FIPS 203, as deployed in production by Google services and Chrome as of 2025.[60][23] These hybrids maintain backward compatibility while providing quantum resistance, with ongoing IETF work in drafts like hybrid ECDHE-ML-KEM for TLS 1.3. The following table summarizes support for key RFC-defined curves across major TLS implementations, indicating full native support, configurable enablement, or partial/limited availability (e.g., in embedded configurations). Support levels are based on standard builds as of 2025; embedded libraries like mbedTLS often require explicit configuration for full suites.| Curve | Security Level (bits) | OpenSSL | GnuTLS | mbedTLS | NSS | BoringSSL |
|---|---|---|---|---|---|---|
| P-256 | 128 | Full | Full | Full | Full | Full |
| P-384 | 192 | Full | Full | Full | Full | Full |
| P-521 | 256 | Full | Full | Config | Full | Full |
| X25519 | 128 | Full | Full | Full | Full | Full |
| X448 | 224 | Full | Full | Config | Full | Full |
Certificate Handling
Certificate Verification Methods
Certificate verification in TLS implementations occurs during the handshake to ensure the authenticity and validity of the presented server certificate. This process typically involves constructing a chain from the leaf certificate to a trusted root certificate authority (CA), verifying signatures along the path, checking revocation status, and confirming the certificate matches the expected hostname. Implementations differ in their default trust anchors, support for revocation protocols, and handling of edge cases like self-signed certificates. Revocation checking prevents the use of compromised certificates by querying whether they have been revoked. Certificate Revocation Lists (CRLs) provide an offline method where clients download a signed list of revoked serial numbers from the issuing CA, which can grow large and require periodic updates, potentially introducing latency. The Online Certificate Status Protocol (OCSP) offers real-time verification by sending a query to the CA's OCSP responder for the specific certificate's status, reducing bandwidth but adding a network dependency and potential privacy risks from query metadata. OCSP Stapling mitigates these issues by allowing the server to include a pre-fetched, signed OCSP response in the TLS handshake (via the Certificate Status Request extension in RFC 6066), enabling efficient client-side validation without direct CA contact. Chain validation requires building a path to a root CA by iteratively verifying issuer signatures and ensuring no loops or missing intermediates. Hostname matching, as defined in RFC 6125, compares the server's presented identity (from the certificate's subjectAltName or commonName) against the expected hostname using case-insensitive string comparison, with support for wildcards but restrictions on IP addresses and internationalized domain names.[62] Certificate pinning, once enabled via HTTP Public Key Pinning (HPKP, RFC 7469), allowed sites to specify expected public keys or hashes to prevent man-in-the-middle attacks, but it was deprecated by Google in Chrome 67 (2018) due to deployment risks like accidental lockouts and low adoption, with full removal in Chrome 72 (2019).[63] Implementation variances arise in trust store management and feature integration. OpenSSL relies on system-wide trust stores, such as the ca-certificates bundle on Linux distributions, loaded via directories like /etc/ssl/certs or explicit files, allowing flexible but OS-dependent configuration.[64] NSS embeds Mozilla's curated root CA list (maintained per the Mozilla Root Store Policy), providing a consistent, browser-aligned set of approximately 100 trusted roots without needing external bundles.[65] BoringSSL, a streamlined fork of OpenSSL, inherits similar verification logic but omits legacy features for reduced attack surface, using the same system trust mechanisms.[66] mbed TLS requires explicit CA chain provision via configuration (e.g., mbedtls_x509_crt_parse), supporting basic path building but lacking built-in OCSP; CRL checks are manual via loaded lists. GnuTLS integrates system trust stores or pkcs11 modules, with native support for OCSP queries and CRL downloading during verification.[67]| Implementation | Trust Store | Revocation Methods | Notes |
|---|---|---|---|
| OpenSSL | System (e.g., ca-certificates) | CRL (via X509_V_FLAG_CRL_CHECK), OCSP (manual or stapling via SSL_CTX_set_tlsext_status_cb) | Flexible but requires configuration for stapling; supports partial chain validation.[68] |
| BoringSSL | System (inherits OpenSSL) | CRL, OCSP stapling | Similar to OpenSSL but stricter defaults; no deprecated algorithms. |
| NSS | Built-in Mozilla roots | CRL (automatic download), OCSP (via CERT_VerifyCert) | Integrated with Firefox; supports stapling and soft-token CRL updates. |
| mbed TLS | Explicit CA files | CRL (manual parsing) | No native OCSP; focuses on embedded use with lightweight chain verify. |
| GnuTLS | System or PKCS#11 | CRL (gnutls_certificate_set_x509_trust), OCSP (gnutls_ocsp_status_request) | Enables OCSP by default if URLs present; supports stapling.[69] |
Certifications and Compliance Standards
TLS implementations undergo rigorous certification processes to ensure they meet security standards required for government, financial, and enterprise use. The Federal Information Processing Standards (FIPS) 140-2 and its successor FIPS 140-3, administered by the National Institute of Standards and Technology (NIST), validate cryptographic modules for compliance with U.S. federal security requirements.[71] OpenSSL's FIPS Provider in version 3.1.2 achieved FIPS 140-3 validation under certificate #4985, effective from March 11, 2025, and valid until March 10, 2030.[72] NSS, used in Mozilla products and Oracle environments, has maintained FIPS 140-2 certification since 2005 through modules like the NSS Softoken, with ongoing validations integrated into Oracle Linux distributions.[73] wolfSSL's wolfCrypt library holds multiple FIPS 140-3 certificates, including #4718 and #5041, both valid through July 17, 2030, supporting embedded and high-performance applications.[6] BoringSSL includes a FIPS module with public NIST validation under certificate #4735 for FIPS 140-3, focused on Google use but available in products like Google Cloud.[74] In contrast, mbed TLS offers partial FIPS readiness through its FIPS-based configuration but lacks full module validation, requiring additional vendor-specific adaptations for compliance. GnuTLS has achieved FIPS 140-3 validation in distributions like AlmaLinux 9 (#5049, valid July 2025–2030) and Oracle Linux 9. LibreSSL removed FIPS support post-fork from OpenSSL, offering no certification. rustls provides FIPS 140-3 compliance via its aws-lc-rs cryptographic backend (no dedicated module certificate).[75][76][77] FIPS certifications follow a five-year validity cycle, after which modules must undergo recertification or risk expiration; for instance, all FIPS 140-2 validations are scheduled to sunset by September 21, 2026, accelerating the transition to FIPS 140-3.[78] This recertification ensures modules address evolving threats, such as those from quantum computing, and maintain operational integrity through self-tests and approved algorithms. The National Security Agency (NSA) Suite B, evolved into the Commercial National Security Algorithm Suite (CNSA) 1.0 and 2.0, specifies algorithms for protecting national security systems (NSS). CNSA 1.0 mandates AES-256 for encryption, SHA-384 for hashing, and elliptic curves like P-384 for key exchange in TLS contexts.[79] OpenSSL supports CNSA 1.0 profiles via configuration, enabling TLS 1.3 implementations compliant with NSA guidelines for protecting classified information up to TOP SECRET.[80] NSS inherently aligns with CNSA 1.0 through its algorithm suite, used in federal systems since the Suite B era.[81] Post-2022, CNSA 2.0 introduces quantum-resistant algorithms, requiring NSS to migrate by 2030-2035 timelines; wolfSSL and OpenSSL have begun integrating post-quantum key exchange (e.g., Kyber) for CNSA 2.0 readiness in TLS.[82] mbed TLS supports CNSA 1.0 algorithms but trails in full CNSA 2.0 quantum migration, with experimental post-quantum extensions. GnuTLS supports CNSA 1.0; rustls offers partial CNSA 2.0 via post-quantum extensions in aws-lc-rs.[5] Other compliance standards include Common Criteria (CC) at Evaluation Assurance Level 4+ (EAL4+), which evaluates overall system security including TLS components, and PCI-DSS for payment card industry data security. CC EAL4+ certifications are typically applied to products embedding TLS libraries, such as firewalls or gateways using OpenSSL or NSS, verifying resistance to deliberate attacks. PCI-DSS Requirement 4 mandates strong cryptography in transit, achievable with TLS 1.2+ using libraries like OpenSSL configured for approved ciphers (e.g., AES-256-GCM), though it certifies environments rather than libraries directly.[83]| Implementation | FIPS Level | Certificate # | Expiration Date | CNSA Support | CC EAL4+ | PCI-DSS Configurable |
|---|---|---|---|---|---|---|
| OpenSSL | 140-3 | 4985 | March 10, 2030 | 1.0/2.0 (PQ) | Product-embedded | Yes |
| NSS | 140-2 | Various (e.g., Oracle-integrated) | Ongoing (pre-2026 sunset) | 1.0 | Product-embedded | Yes |
| mbed TLS | Partial (140-2 ready) | N/A | N/A | 1.0 (partial 2.0) | Limited | Yes |
| wolfSSL | 140-3 | 4718, 5041 | July 17, 2030 | 1.0/2.0 (PQ) | Product-embedded | Yes |
| BoringSSL | 140-3 | 4735 | N/A | 1.0 | N/A | Yes |
| GnuTLS | 140-3 | 5049 (e.g., AlmaLinux 9) | July 27, 2030 | 1.0 | Product-embedded | Yes |
| LibreSSL | None | N/A | N/A | 1.0 | Limited | Yes |
| rustls | 140-3 (via aws-lc-rs) | N/A | N/A | 1.0 (partial 2.0 PQ) | Limited | Yes |
Advanced Features
Compression Support
Transport Layer Security (TLS) originally included support for compressing the payload of TLS records to reduce bandwidth usage, primarily through the DEFLATE algorithm defined in RFC 3749. This method, which employs the zlib library for deflate compression, was intended to optimize data transmission in bandwidth-constrained environments but introduced significant security risks due to the compress-then-encrypt paradigm. The compression process could leak information about plaintext through variations in compressed output size, enabling side-channel attacks. The CRIME attack, disclosed in 2012, exploited DEFLATE compression in TLS to infer sensitive data such as authentication cookies by analyzing compression ratios over multiple connections. This vulnerability, classified as CVE-2012-4929, demonstrated how an active network attacker could progressively reveal secrets by injecting crafted content and observing encrypted packet lengths. A related attack, BREACH, extended similar principles to HTTP-level compression but highlighted the broader dangers of compression in secure channels, though it primarily affected application-layer gzip rather than TLS records. Following CRIME, major TLS implementations disabled compression by default; for instance, OpenSSL versions 1.0.1 and later rejected the compression extension during handshake negotiation.[84][85] TLS 1.3, standardized in RFC 8446, eliminated record-layer compression entirely to mitigate these risks, removing the compression method field from the record layer and prohibiting any payload compression. Legacy support for DEFLATE and other methods like LZS (from RFC 3943) persists only in older TLS versions (1.0–1.2) for backward compatibility, but it is widely discouraged and often compiled out in modern libraries. GnuTLS, for example, removed record-layer compression support starting with version 3.6.0, citing security concerns, while retaining optional legacy modes for interoperability in constrained environments. In contrast, BoringSSL, Google's security-focused fork of OpenSSL, never implemented record-layer compression to avoid vulnerabilities from the outset.[9][86] As an alternative to TLS-level compression, application-layer methods like gzip for HTTP content remain viable and are recommended, as they occur after encryption and avoid side-channel leaks in the transport layer. These operate independently of TLS, compressing response bodies without exposing plaintext patterns to network observers.[87] More recently, TLS 1.3 introduced certificate compression via RFC 8879 to reduce handshake overhead without compromising payload security. This extension allows compressing the certificate chain using algorithms like Brotli (zlib-based but optimized for web content), Zstandard, or zlib, negotiated separately from record compression. Brotli support is experimental in some contexts but standardized here, with implementations varying: OpenSSL provides Brotli via its COMP_brotli method since version 3.0, GnuTLS enables it through gnutls_compress_certificate_set_methods since 3.7.0, and BoringSSL supports it via SSL_CTX_add_cert_compression_alg callbacks. This feature achieves significant size reduction for large certificate chains, enhancing performance on mobile networks without the risks of record compression.[88][89][90][91]| Implementation | Record-Layer Compression (DEFLATE/LZS) | Certificate Compression (Brotli/Zstd/etc.) |
|---|---|---|
| OpenSSL | Disabled by default (1.0.1+); removable | Supported (3.0+ incl. Brotli) |
| GnuTLS | Removed (3.6.0+); legacy optional | Supported (3.7.0+ incl. Brotli) |
| BoringSSL | Never supported | Supported (via callbacks incl. Brotli) |
| mbed TLS | Removed (3.0+) | Not supported |
Assisted Cryptography
Assisted cryptography in TLS implementations refers to the offloading of cryptographic operations, such as key exchanges and encryption during handshakes, to external hardware or modules to enhance performance and security. This approach allows TLS libraries to delegate resource-intensive tasks like RSA or ECDH computations to specialized devices, reducing computational load on the host system while maintaining protocol integrity. Major TLS libraries integrate these capabilities through standardized interfaces, enabling seamless support for hardware-accelerated operations in both client and server contexts.[92] Key features include support for the PKCS#11 interface, which provides a platform-independent API for interacting with hardware security modules (HSMs) and cryptographic tokens, facilitating secure key storage and operations without exposing sensitive material to the host environment. In OpenSSL, the ENGINE API historically enabled plugin-based integration for such offloading, though it has been deprecated in favor of the more modular provider interface since version 3.0, allowing dynamic loading of PKCS#11 providers for algorithms like RSA and elliptic curve operations. NSS, by contrast, embeds PKCS#11 natively as its core architecture, treating HSMs as pluggable modules for TLS key management.[93] Implementation details vary across libraries, with NSS offering the most direct integration by registering PKCS#11 modules during initialization, enabling TLS handshakes to use hardware-backed keys transparently for operations like certificate signing and key derivation. mbed TLS supports assisted cryptography through external plugins and its Platform Security Architecture (PSA) cryptography API, which allows interfacing with HSMs via driver layers, though full PKCS#11 compatibility relies on wrappers like pkcs11-helper that are now deprecated in favor of PSA secure element interfaces. wolfSSL provides robust built-in PKCS#11 support, both as a consumer of external modules and as a provider via its wolfPKCS11 library, optimizing for embedded TLS scenarios. BoringSSL, a streamlined OpenSSL fork, facilitates offloading through custom private key method callbacks, supporting asynchronous hardware acceleration for TLS private key operations without native PKCS#11 but compatible via upstream mechanisms.[94] Common use cases involve offloading RSA or ECDH key exchanges to smart cards or HSMs in high-throughput environments, such as web servers handling thousands of TLS connections, where hardware acceleration can handle 33% more requests per second compared to software-only implementations. For instance, in enterprise TLS deployments, HSMs handle private key operations during certificate authentication, ensuring scalability for protocols like TLS 1.3 while minimizing CPU overhead on the application server.[95] Security trade-offs in assisted modes center on balancing enhanced key protection against potential vulnerabilities; while HSMs prevent key exposure by confining operations within tamper-resistant boundaries—reducing risks from memory dumps or side-channel attacks on host systems—they introduce dependencies on hardware integrity and may incur latency from inter-module communication. Key exposure risks are mitigated in HSM-assisted TLS by never exporting private keys, unlike software modes where keys reside in volatile memory, but compromise of the HSM itself remains a concern if not FIPS 140 validated. Post-2020 mitigations include OpenSSL's shift to provider-based architectures, which isolate third-party modules to limit attack surfaces, and NIST guidelines emphasizing automated key rotation in HSMs to counter prolonged exposure during certificate lifecycles.[92]Alternative Key Exchange Support
Alternative key exchange mechanisms in TLS provide options beyond traditional certificate-based authentication, enabling authentication through pre-shared secrets or passwords. These approaches are particularly useful in environments where public key infrastructure (PKI) is impractical or resource-intensive. Pre-shared key (PSK) ciphersuites, defined in RFC 4279, allow parties to authenticate using symmetric keys shared out-of-band, supporting both pure PSK modes and hybrid variants that incorporate ephemeral Diffie-Hellman (DHE-PSK) for forward secrecy.[46] In DHE-PSK hybrids, the PSK handles authentication while DHE generates ephemeral keys to protect against key compromise, as specified in the same RFC for TLS versions prior to 1.3.[46] Additionally, the Secure Remote Password (SRP) protocol enables password-authenticated key exchange, where a verifier derived from the password facilitates mutual authentication without transmitting the password itself, per RFC 5054.[96] In TLS 1.3, PSK support is integrated into the core protocol (RFC 8446), allowing resumption of prior sessions with pre-shared keys for reduced latency. A key feature is 0-RTT (zero round-trip time) resumption, where clients can send encrypted application data immediately in the ClientHello using the PSK, though this trades some security for performance by risking replay attacks on early data.[9] The TLS 1.3 key schedule derives all secrets, including those for PSK modes, using HKDF-Expand-Label, a construct from HKDF (RFC 5869) that expands pseudorandom keys into labeled subkeys for traffic protection and key updates.[9] SRP integration remains available in earlier TLS versions but is not natively extended to TLS 1.3, as the protocol favors PSK for low-entropy secrets with additional protections like key ratcheting.[96] These mechanisms find prominent use in resource-constrained settings, such as Internet of Things (IoT) devices, where avoiding PKI overhead simplifies deployment and reduces computational demands. PSK enables lightweight authentication for low-power sensors or embedded systems communicating with gateways, ensuring confidentiality without certificate management.[97] SRP suits scenarios requiring human-memorable passwords, like legacy device logins, while hybrids like DHE-PSK balance efficiency with forward secrecy in bandwidth-limited networks.[98] Support for these features varies across TLS implementations, with full PSK commonly available but SRP more limited due to its niche adoption and deprecation in some libraries.| Implementation | PSK Support (incl. TLS 1.3 & 0-RTT) | DHE-PSK Hybrid | SRP Support |
|---|---|---|---|
| OpenSSL | Full, via API callbacks for external PSKs[99] | Yes (pre-TLS 1.3)[46] | Deprecated in 3.x versions; available in 1.1.x via srp command[100] |
| GnuTLS | Full, with credential functions and priority strings[101] | Yes (pre-TLS 1.3)[102] | Full, via dedicated authentication mode and srptool[103] |
| BoringSSL | Supported for internal PSKs; external PSKs limited in TLS 1.3[104] | Yes (pre-TLS 1.3)[105] | No native support |
| NSS | Full for TLS 1.3 resumption PSKs[106] | Yes (pre-TLS 1.3)[107] | No native support |
| wolfSSL | Full (incl. TLS 1.3 & 0-RTT) | Yes (pre-TLS 1.3) | Limited; available via external integration |
Implementation Aspects
System-Specific Backends
TLS implementations often integrate with operating system-specific cryptographic backends to leverage native APIs for enhanced security, performance, and compliance with platform standards. These backends provide access to underlying cryptographic primitives, certificate stores, and hardware acceleration without requiring custom code, allowing TLS libraries to offload tasks like key generation, encryption, and verification to the OS level.[108][109][50] On Windows, the Schannel Security Support Provider (SSP) serves as the primary TLS backend, utilizing the Cryptography API: Next Generation (CNG) and legacy CryptoAPI (CAPI) for cryptographic operations such as public key handling and symmetric encryption in TLS 1.0 through 1.3. Schannel integrates seamlessly with Windows' certificate store and supports protocols like DTLS, enabling applications to establish secure connections via the Security Support Provider Interface (SSPI) while automatically benefiting from OS updates to cipher suites and vulnerabilities. This approach ensures compliance with Windows security policies but ties implementations closely to Microsoft ecosystems, limiting cross-platform reuse.[108] For macOS and iOS, the Security Framework provides the Secure Transport API as the core TLS backend, supporting TLS 1.0 to 1.3 and DTLS with preferences for forward secrecy and AES-based ciphers. It handles certificate validation per RFC 5280 and OCSP stapling via RFC 6962, integrating with the system's keychain for credential management and enforcing policies like App Transport Security (ATS) to mandate TLS 1.2+ and strong hashing. Secure Transport deprecates weaker algorithms like RC4 and SHA-1, promoting secure defaults, though it lacks native TLS 1.3 support in older APIs, directing developers to higher-level frameworks like Network.framework for modern features. This backend excels in Apple's unified security model but requires adaptation for non-Apple platforms.[110] In Linux environments, the kernel TLS (kTLS) implementation utilizes the kernel crypto API to perform symmetric encryption and decryption directly in kernel space, supporting TLS 1.2 and 1.3 over TCP sockets via setsockopt options like TLS_TX and TLS_RX. Post-handshake, user-space applications can offload record processing to the kernel, which handles ciphers such as AES-GCM using structures like tls12_crypto_info_aes_gcm_128, reducing data copies between user and kernel space. This integration enables efficient zero-copy operations with sendfile and supports key updates for TLS 1.3, with statistics trackable via /proc/net/tls_stat. kTLS enhances throughput for high-load scenarios, such as in NGINX, by up to 29% on certain distributions through minimized context switches and hardware offload compatibility.[109][111] Cross-platform TLS libraries like Network Security Services (NSS) address portability by relying on the Netscape Portable Runtime (NSPR) as an abstraction layer over OS-specific APIs, allowing consistent TLS behavior across Windows, Linux, and Unix-like systems without direct backend dependencies. NSS uses NSPR for threading, I/O, and memory management, enabling it to interface with platform crypto providers while maintaining a unified API for TLS handshakes and session management. In contrast, BoringSSL, a fork of OpenSSL tailored for Google's services, integrates tightly with Chromium's networking stack, optimizing for browser-specific needs like QUIC over TLS but forgoing broad OS backend abstraction in favor of custom performance tweaks.[112][113] System-specific backends offer advantages in performance and automatic hardware utilization—such as NIC offload for encryption—reducing CPU overhead compared to pure user-space implementations, though they sacrifice portability by requiring platform recompilation or wrappers. For instance, kTLS can halve latency in data transfers by avoiding user-kernel copies, but cross-platform libraries like NSS mitigate this via NSPR at the cost of potential overhead. OpenSSL 3.0, released in 2021, introduces a provider-based architecture to enhance modularity, allowing dynamic loading of backends like the default (standard algorithms), FIPS (validated module), or legacy providers via OSSL_PROVIDER_load, with system-specific paths such as fips.so on Unix or fips.dll on Windows. This enables OpenSSL to adapt to OS crypto APIs more flexibly than prior versions' engine interface, supporting hybrid deployments.[111][50]| Implementation | Primary Backend(s) | Key Advantages | Key Disadvantages |
|---|---|---|---|
| Schannel (Windows native) | CNG/CAPI | Native certificate integration; automatic OS updates | Windows-only; limited customization |
| Secure Transport (macOS) | Security Framework | Enforced secure defaults (e.g., ATS); keychain support | Deprecated older APIs; Apple ecosystem lock-in |
| kTLS (Linux) | Kernel Crypto API | Kernel-level offload for high throughput; zero-copy | Requires kernel 4.13+; user-space handshake needed |
| NSS | NSPR abstraction | Cross-platform portability | Abstraction layer overhead |
| BoringSSL | Chromium stack | Browser-optimized performance | Not general-purpose; no ABI stability |
| OpenSSL 3.0+ | Modular providers (e.g., default, FIPS) | Dynamic backend loading; FIPS compliance | Configuration complexity for multi-provider setups |
Hardware Token and Module Support
TLS implementations often integrate with hardware tokens and modules to enhance security by offloading sensitive cryptographic operations, such as key generation, storage, and usage during TLS handshakes, to tamper-resistant devices. The PKCS#11 standard provides a platform-independent API for accessing these hardware cryptographic tokens, enabling uniform interaction with devices like hardware security modules (HSMs) and smart cards for tasks including private key protection and signature generation in TLS sessions.[114] GnuTLS supports PKCS#11 hardware tokens through integration with the p11-kit library, which manages module loading and configuration, allowing applications to perform TLS operations like certificate verification and key derivation using tokens without exposing private keys. OpenSSL achieves similar functionality via the engine_pkcs11 library, which acts as an engine to route cryptographic calls to PKCS#11-compliant hardware modules during TLS negotiations. The Network Security Services (NSS) library also natively supports PKCS#11 tokens for secure key management in TLS contexts, facilitating integration with various hardware accelerators and smart cards. For instance, the YubiHSM 2 device exposes its capabilities through a PKCS#11 module, enabling TLS servers to use it for encryption and signing while keeping keys confined to the hardware.[115][116][117][118] Trusted Platform Module (TPM) 2.0 integration further extends hardware support in TLS by allowing keys stored in the TPM to be used for authentication and encryption without extraction. OpenSSL incorporates TPM 2.0 via the tpm2-openssl provider, which exposes TPM keys through the standard OpenSSL API for seamless TLS use. GnuTLS provides TPM 2.0 support through its API, enabling applications to list and utilize TPM-stored keys for TLS client and server authentication. NSS can interface with TPM 2.0 via PKCS#11 wrappers, supporting secure key operations in browser-based TLS sessions.[119][120][121] Hardware tokens and modules compliant with FIPS 140 Level 3 (under standards such as FIPS 140-2 or the current FIPS 140-3) ensure robust physical security for key storage and generation in TLS environments, featuring tamper detection and response mechanisms to protect against unauthorized access. These certified devices, such as PCIe-based accelerators, support TLS protocol acceleration while maintaining key confidentiality, as validated by NIST for cryptographic modules used in secure communications. Usage typically involves storing private keys non-exportably and performing operations like RSA or ECDSA signing directly on the hardware during TLS handshakes.[122][123] Challenges in hardware integration include configuration complexities and potential dependencies on vendor-specific drivers, which can lead to optimization for particular modules like nCipher HSMs in NSS setups, potentially complicating migrations to alternative hardware. Such vendor-specific tuning may enhance performance for TLS workloads but risks interoperability issues across diverse token ecosystems. This hardware offloading can briefly assist features like cryptography acceleration by delegating compute-intensive tasks to specialized modules.[124]Code Dependencies
TLS implementations vary in their reliance on external libraries for core functionality such as ASN.1 parsing and arbitrary-precision arithmetic, which are common across many libraries to handle certificate processing and cryptographic operations. For instance, GnuTLS requires the libtasn1 library for ASN.1 structure handling in X.509 certificates and related protocols.[125] Similarly, big-integer arithmetic libraries like GMP are often used indirectly; in GnuTLS, GMP is a dependency of the Nettle cryptographic backend for operations such as Diffie-Hellman key exchange.[126] OpenSSL, by contrast, implements its own bignum library and does not mandate external big-integer support, though optional engines may integrate third-party arithmetic libraries.[127] Implementation-specific dependencies reflect design goals, such as portability or integration with larger ecosystems. BoringSSL, a fork of OpenSSL tailored for Google's infrastructure, maintains minimal external dependencies at runtime and integrates seamlessly with Go's standard crypto package for applications in that language, relying primarily on standard C libraries. mbed TLS is designed as a standalone library with no external cryptographic dependencies, using only standard C library functions to minimize footprint for embedded systems.[128] NSS depends on NSPR for portable runtime services and zlib for compression, ensuring cross-platform compatibility without broader external crypto libraries.[129] Dependencies introduce vulnerability risks through supply-chain attacks, where compromised third-party components can propagate flaws, akin to the 2021 Log4j incident that affected numerous Java-based systems via logging library dependencies.[130] In TLS contexts, outdated or vulnerable dependencies like those in OpenSSL distributions have led to exposures such as CVE-2022-3602, highlighting the need for vigilant updates; for example, UEFI firmware using embedded OpenSSL versions faced supply-chain risks from unpatched variants.[131] Update cadences vary: GnuTLS dependencies like Nettle and GMP receive regular releases, but synchronization lags can expose systems if not managed, as seen in historical mismatches affecting cryptographic integrity.[132] The following table summarizes core and optional dependencies for select implementations, along with approximate minimal binary sizes for TLS functionality (stripped configurations on x86_64 Linux):| Implementation | Core Dependencies | Optional Dependencies | Approx. Binary Size |
|---|---|---|---|
| OpenSSL | Standard C libraries, Perl (build) | None (self-contained crypto) | ~3.2 MB |
| GnuTLS | libtasn1, Nettle (incl. GMP) | p11-kit, libunistring | ~1.7 MB |
| BoringSSL | Standard C libraries | Go (tests/integration) | ~3 MB |
| mbed TLS | Standard libc | None | ~420 KB |
| NSS | NSPR, zlib | None | ~2 MB |