OpenSSL

Last updated

OpenSSL
Developer(s) The OpenSSL Project
Initial release1998;26 years ago (1998)
Stable release
Stable3.4.0 [1]   OOjs UI icon edit-ltr-progressive.svg / 22 October 2024
Repository
Written in C, Assembly, Perl
Type Cryptography library
License 3.0 and later: Apache-2.0 [2]
1.x and earlier: OpenSSL [3]
Website www.openssl.org

OpenSSL is a software library for applications that provide secure communications over computer networks against eavesdropping, and identify the party at the other end. It is widely used by Internet servers, including the majority of HTTPS websites.

Contents

OpenSSL contains an open-source implementation of the SSL and TLS protocols. The core library, written in the C programming language, implements basic cryptographic functions and provides various utility functions. Wrappers allowing the use of the OpenSSL library in a variety of computer languages are available.

The OpenSSL Software Foundation (OSF) represents the OpenSSL project in most legal capacities including contributor license agreements, managing donations, and so on. OpenSSL Software Services (OSS) also represents the OpenSSL project for support contracts.

OpenSSL is available for most Unix-like operating systems (including Linux, macOS, and BSD), Microsoft Windows and OpenVMS.

Project history

The OpenSSL project was founded in 1998 to provide a free set of encryption tools for the code used on the Internet. It is based on a fork of SSLeay by Eric Andrew Young and Tim Hudson, which unofficially ended development on December 17, 1998, when Young and Hudson both went to work for RSA Security. The initial founding members were Mark Cox, Ralf Engelschall, Stephen Henson, Ben Laurie, and Paul Sutton. [4]

In 2018 OpenSSL version numbering skipped from 1.1.1 to 3.0.0, omitting 2 as a major version number to avoid a conflict with one of OpenSSL's modules. Version 3.0.0 was the first to use the Apache License.

As of May 2019, [5] the OpenSSL management committee consisted of seven people [6] and there are seventeen developers [7] with commit access (many of whom are also part of the OpenSSL management committee). There are only two full-time employees (fellows) and the remainder are volunteers.

The project has a budget of less than $1 million USD per year and relies primarily on donations. Development of TLS 1.3 was sponsored by Akamai. [8]

Major version releases

OpenSSL release history [9] [10]
VersionOriginal release dateSupport until [11] CommentLast minor version
Old version, no longer maintained: 0.9.1 [12] 23 December 1998
  • Official start of the OpenSSL project
0.9.1c (23 December 1998)
Old version, no longer maintained: 0.9.2 [12] 22 March 1999
  • Successor of 0.9.1c
0.9.2b (6 April 1999)
Old version, no longer maintained: 0.9.3 [12] 25 May 1999
  • Successor of 0.9.2b
0.9.3a (27 May 1999)
Old version, no longer maintained: 0.9.4 [12] 9 August 1999
  • Successor of 0.9.3a
0.9.4 (9 August 1999)
Old version, no longer maintained: 0.9.5 [12] 28 February 2000
  • Successor of 0.9.4
0.9.5a (1 April 2000)
Old version, no longer maintained: 0.9.6 [12] 24 September 2000
  • Successor of 0.9.5a
0.9.6m (17 March 2004)
Old version, no longer maintained: 0.9.7 [12] 31 December 2002
  • Successor of 0.9.6m
0.9.7m (23 February 2007)
Old version, no longer maintained: 0.9.8 [12] 5 July 2005
  • Successor of 0.9.7m
0.9.8zh (3 December 2015)
Old version, no longer maintained: 1.0.0 [13] 29 March 2010
  • Successor of 0.9.8n
1.0.0t (3 December 2015)
Old version, no longer maintained: 1.0.1 [14] 14 March 201231 December 2016
  • Successor of 1.0.0h
  • Support for TLS/DTLS heartbeat [15]
  • Support for SCTP
  • Support for TLS keying material exporter [16]
  • Support for DTLS key establishment for SRTP [17]
  • Next Protocol Negotiation
  • PSS signatures in certificates, requests and certificate revocation lists (CRL)
  • Support for password based recipient info for CMS
  • Support for TLS 1.2 and TLS 1.1
  • Preliminary FIPS 140 capability for unvalidated 2.0 FIPS module
  • Secure Remote Password protocol (SRP) support
1.0.1u (22 September 2016)
Old version, no longer maintained: 1.0.2 [18] 22 January 201531 December 20191.0.2u (20 December 2019)
Old version, no longer maintained: 1.1.0 [19] 25 August 201611 September 2019
  • Successor of 1.0.2h
  • Support for BLAKE2 [20]
  • Support for ChaCha20-Poly1305 [21]
  • Support for X25519 [22]
  • Support for DANE and Certificate Transparency
  • Support for CCM Ciphersuites
  • Support for extended master secret
  • SSLv2 removed
  • Kerberos ciphersuite support removed
  • RC4 and 3DES removed from DEFAULT ciphersuites in libssl
  • Remove DSS, SEED, IDEA, CAMELLIA, and AES-CCM from the DEFAULT cipherlist
  • 40 and 56 bit cipher support removed from libssl
  • FIPS 140 support removed
1.1.0l (10 September 2019)
Old version, no longer maintained: 1.1.1 LTS [23] [24] 11 September 201811 September 2023 (LTS)1.1.1w (11 September 2023)
Old version, yet still maintained: 3.0.0 LTS [27] [28]
[note 1] 		7 September 20217 September 2026 (LTS)Ongoing development
Old version, yet still maintained: 3.1.0 [30] [31] 14 March 202314 March 2025Ongoing development
Old version, yet still maintained: 3.2.0 [32] [33] 23 November 202323 November 2025
  • Client-side QUIC support
  • TLS Certificate compression [34]
  • Deterministic use of ECDSA [35]
  • TLS raw public keys [36]
Ongoing development
Old version, yet still maintained: 3.3.0 [37] 9 April 20249 April 2026Ongoing development
Current stable version:3.4.0 [38] 22 October 202422 October 2026Ongoing development
Legend:
Old version, not maintained
Old version, still maintained
Latest version
Latest preview version
Future release

Algorithms

OpenSSL supports a number of different cryptographic algorithms:

Ciphers
AES, Blowfish, Camellia, ChaCha20, Poly1305, SEED, CAST-128, DES, IDEA, RC2, RC4, RC5, Triple DES, GOST 28147-89, [39] SM4
Cryptographic hash functions
MD5, MD4, MD2, SHA-1, SHA-2, SHA-3, RIPEMD-160, MDC-2, GOST R 34.11-94, [39] BLAKE2, Whirlpool, [40] SM3
Public-key cryptography
RSA, DSA, Diffie–Hellman key exchange, Elliptic curve, X25519, Ed25519, X448, Ed448, GOST R 34.10-2001, [39] SM2

(Perfect forward secrecy is supported using elliptic curve Diffie–Hellman since version 1.0. [41] )

FIPS 140 validation

FIPS 140 is a U.S. Federal program for the testing and certification of cryptographic modules. An early FIPS 140-1 certificate for OpenSSL's FOM 1.0 was revoked in July 2006 "when questions were raised about the validated module's interaction with outside software." The module was re-certified in February 2007 before giving way to FIPS 140-2. [42] OpenSSL 1.0.2 supported the use of the OpenSSL FIPS Object Module (FOM), which was built to deliver FIPS approved algorithms in a FIPS 140-2 validated environment. [43] [44] OpenSSL controversially decided to categorize the 1.0.2 architecture as 'end of life' or 'EOL', effective December 31, 2019, despite objections that it was the only version of OpenSSL that was currently available with support for FIPS mode. [45] As a result of the EOL, many users were unable to properly deploy the FOM 2.0 and fell out of compliance because they did not secure extended support for the 1.0.2 architecture, although the FOM itself remained validated for eight months further.

The FIPS Object Module 2.0 remained FIPS 140-2 validated in several formats until September 1, 2020, when NIST deprecated the usage of FIPS 186-2 for Digital Signature Standard and designated all non-compliant modules as 'Historical'. This designation includes a caution to federal agencies that they should not include the module in any new procurements. All three of the OpenSSL validations were included in the deprecation – the OpenSSL FIPS Object Module (certificate #1747), [46] OpenSSL FIPS Object Module SE (certificate #2398), [47] and OpenSSL FIPS Object Module RE (certificate #2473). [48] Many 'private label' OpenSSL-based validations and clones created by consultants were also moved to the Historical List, although some FIPS validated modules with replacement compatibility avoided the deprecation, such as BoringCrypto from Google [49] and CryptoComply from SafeLogic. [50]

The OpenSSL Management Committee announced a change in the versioning scheme.

Due to this change, the major number of the next major version would have been doubled, since the OpenSSL FIPS module already occupied this number. Therefore the decision was made to skip the OpenSSL 2.0 version number and continue with OpenSSL 3.0 .

OpenSSL 3.0 restored FIPS mode and underwent FIPS 140-2 testing, but with significant delays: The effort was first kicked off in 2016 with support from SafeLogic [51] [52] [53] and further support from Oracle in 2017, [54] [55] but the process has been challenging. [56]

On October 20, 2020, the OpenSSL FIPS Provider 3.0 was added to the CMVP Implementation Under Test List, which reflected an official engagement with a testing lab to proceed with a FIPS 140-2 validation. This resulted in a slew of certifications in the following months. [57]

Licensing

OpenSSL was dual-licensed under the OpenSSL License and the SSLeay License, which means that the terms of either licenses can be used. [58] The OpenSSL License is Apache License 1.0 and SSLeay License bears some similarity to a 4-clause BSD License. As the OpenSSL License was Apache License 1.0, but not Apache License 2.0, it requires the phrase "this product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit" to appear in advertising material and any redistributions (Sections 3 and 6 of the OpenSSL License). Due to this restriction, the OpenSSL License and the Apache License 1.0 are incompatible with the GNU GPL. [59] Some GPL developers have added an OpenSSL exception to their licenses that specifically permits using OpenSSL with their system. GNU Wget and climm both use such exceptions. [60] [61] Some packages (like Deluge) explicitly modify the GPL license by adding an extra section at the beginning of the license documenting the exception. [62] Other packages use the LGPL-licensed GnuTLS, BSD-licensed Botan, or MPL-licensed NSS, which perform the same task.

OpenSSL announced in August 2015 that it would require most contributors to sign a Contributor License Agreement (CLA), and that OpenSSL would eventually be relicensed under the terms of Apache License 2.0. [63] This process commenced in March 2017, [64] and was complete in 2018. [65]

On 7 September 2021, OpenSSL 3.0.0 was released under the Apache License 2.0. [66]

Notable vulnerabilities

Denial of service: ASN.1 parsing

OpenSSL 0.9.6k has a bug where certain ASN.1 sequences triggered a large number of recursions on Windows machines, discovered on November 4, 2003. Windows could not handle large recursions correctly, so OpenSSL would crash as a result. Being able to send arbitrary large numbers of ASN.1 sequences would cause OpenSSL to crash as a result.

OCSP stapling vulnerability

When creating a handshake, the client could send an incorrectly formatted ClientHello message, leading to OpenSSL parsing more than the end of the message. Assigned the identifier CVE - 2011-0014 by the CVE project, this affected all OpenSSL versions 0.9.8h to 0.9.8q and OpenSSL 1.0.0 to 1.0.0c. Since the parsing could lead to a read on an incorrect memory address, it was possible for the attacker to cause a DoS. It was also possible that some applications expose the contents of parsed OCSP extensions, leading to an attacker being able to read the contents of memory that came after the ClientHello. [67]

ASN.1 BIO vulnerability

When using Basic Input/Output (BIO) [68] or FILE based functions to read untrusted DER format data, OpenSSL is vulnerable. This vulnerability was discovered on April 19, 2012, and was assigned the CVE identifier CVE - 2012-2110. While not directly affecting the SSL/TLS code of OpenSSL, any application that was using ASN.1 functions (particularly d2i_X509 and d2i_PKCS12) were also not affected. [69]

SSL, TLS and DTLS plaintext recovery attack

In handling CBC cipher-suites in SSL, TLS, and DTLS, OpenSSL was found vulnerable to a timing attack during the MAC processing. Nadhem Alfardan and Kenny Paterson discovered the problem, and published their findings [70] on February 5, 2013. The vulnerability was assigned the CVE identifier CVE - 2013-0169.

Predictable private keys (Debian-specific)

OpenSSL's pseudo-random number generator acquires entropy using complex programming methods. To keep the Valgrind analysis tool from issuing associated warnings, a maintainer of the Debian distribution applied a patch to Debian's variant of the OpenSSL suite, which inadvertently broke its random number generator by limiting the overall number of private keys it could generate to 32,768. [71] [72] The broken version was included in the Debian release of September 17, 2006 (version 0.9.8c-1), also compromising other Debian-based distributions, for example Ubuntu. Ready-to-use exploits are easily available. [73]

The error was reported by Debian on May 13, 2008. On the Debian 4.0 distribution (etch), these problems were fixed in version 0.9.8c-4etch3, while fixes for the Debian 5.0 distribution (lenny) were provided in version 0.9.8g-9. [74]

Heartbleed

A logo representing the Heartbleed bug Heartbleed.svg
A logo representing the Heartbleed bug

OpenSSL versions 1.0.1 through 1.0.1f have a severe memory handling bug in their implementation of the TLS Heartbeat Extension that could be used to reveal up to 64  KB of the application's memory with every heartbeat [75] [76] (CVE - 2014-0160). By reading the memory of the web server, attackers could access sensitive data, including the server's private key. [77] This could allow attackers to decode earlier eavesdropped communications if the encryption protocol used does not ensure perfect forward secrecy. Knowledge of the private key could also allow an attacker to mount a man-in-the-middle attack against any future communications.[ citation needed ] The vulnerability might also reveal unencrypted parts of other users' sensitive requests and responses, including session cookies and passwords, which might allow attackers to hijack the identity of another user of the service. [78]

At its disclosure on April 7, 2014, around 17% or half a million of the Internet's secure web servers certified by trusted authorities were believed to have been vulnerable to the attack. [79] However, Heartbleed can affect both the server and client.

CCS injection vulnerability

The CCS Injection Vulnerability (CVE - 2014-0224) is a security bypass vulnerability that results from a weakness in OpenSSL methods used for keying material. [80]

This vulnerability can be exploited through the use of a man-in-the-middle attack, [81] where an attacker may be able to decrypt and modify traffic in transit. A remote unauthenticated attacker could exploit this vulnerability by using a specially crafted handshake to force the use of weak keying material. Successful exploitation could lead to a security bypass condition where an attacker could gain access to potentially sensitive information. The attack can only be performed between a vulnerable client and server.

OpenSSL clients are vulnerable in all versions of OpenSSL before the versions 0.9.8za, 1.0.0m and 1.0.1h. Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution. [82]

ClientHello sigalgs DoS

This vulnerability (CVE - 2015-0291) allows anyone to take a certificate, read its contents and modify it accurately to abuse the vulnerability causing a certificate to crash a client or server. If a client connects to an OpenSSL 1.0.2 server and renegotiates with an invalid signature algorithms extension, a null-pointer dereference occurs. This can cause a DoS attack against the server.

A Stanford Security researcher, David Ramos, had a private exploit and presented it to the OpenSSL team, which then patched the issue.

OpenSSL classified the bug as a high-severity issue, noting version 1.0.2 was found vulnerable. [83]

Key recovery attack on Diffie–Hellman small subgroups

This vulnerability (CVE - 2016-0701) allows, when some particular circumstances are met, to recover the OpenSSL server's private Diffie–Hellman key. An Adobe System Security researcher, Antonio Sanso, privately reported the vulnerability.

OpenSSL classified the bug as a high-severity issue, noting only version 1.0.2 was found vulnerable. [84]

Forks

Agglomerated SSL

In 2009, after frustrations with the original OpenSSL API, Marco Peereboom, an OpenBSD developer at the time, forked the original API by creating Agglomerated SSL (assl), [85] which reuses OpenSSL API under the hood, but provides a much simpler external interface. [86] It has since been deprecated in light of the LibreSSL fork circa 2015.

LibreSSL

In April 2014 in the wake of Heartbleed, members of the OpenBSD project forked OpenSSL starting with the 1.0.1g branch, to create a project named LibreSSL. [87] In the first week of pruning the OpenSSL's codebase, more than 90,000 lines of C code had been removed from the fork. [88]

BoringSSL

In June 2014, Google announced its own fork of OpenSSL dubbed BoringSSL. [89] Google plans to co-operate with OpenSSL and LibreSSL developers. [90] [91] [92] Google has since developed a new library, Tink, based on BoringSSL. [93]

AWS-LC

In September 2020, it was released as a general-purpose cryptographic library maintained by the AWS Cryptography team to be used in the AWS cloud computing platform. It іs based on code from the OpenSSL and BoringSSL projects. [94]

Criticisms

Backwards compatibility

Among developers communities, OpenSSL is often cited for introducing API compatibility breakage with each new major version, [95] [96] [97] [98] which requires software adaptations that tend to delay new version adoptions. [99] This, combined with the fact that previous releases are generally maintained for no more than two years after a new major one is released [27] tends to force some vendors to anticipate software migrations very early while still having little time left [100] to update to a new release, sometimes at the risk of losing some compatibility with existing software [101] [102] or risking regressions. [103] [104]

Delay between releases

While long-term support (LTS) releases are maintained for 5 years, [11] accumulated delays in release time frames tend to force operating system vendors to stay on the last supported release longer, leaving less margin when the new version is available. For example OpenSSL 3.0 was initially expected for Q4 2019 [45] and was finally issued 21 months later [27] without extending the expected end of support for previously supported version 1.1.1, and this despite the significant changes that required adaptations to existing software.

Significant performance regressions

The reduced support delay of version 1.1.1 mentioned above causes further concerns to users whose workloads are sensitive to performance. Some time after general availability of 3.0, some users started to report serious performance regressions affecting this version in multi-threaded environments, many citing the inefficient use of locks in frequent low-level operations, citing slowdowns from 80 to 400 times. [105] [106] [107] [108] [109] [110] [111] [112] The OpenSSL team has created a meta-issue to try to centralize reports of such massive performance regressions. [113] About half of these reporters indicate the impossibility for them to upgrade to 3.0 from earlier versions, adding to the trouble caused by the limited support time left on previous version 1.1.1.

Consideration for users' requirements

While the QUIC transport layer was being worked on to support the third version of the HTTP protocol, it was proposed to use TLS to provide security, [114] and identified that some adaptations to TLS libraries would be needed. Such modifications were brought to BoringSSL [115] which was the library being primarily used by QUIC developers by then, and later ported to other libraries. [116] A port of this work was quickly proposed to OpenSSL. [117] While some discussion started the same day, it quickly stalled and was first blocked on license considerations, [117] then kept on hold once these concerns were cleared. Finally 10 months later the OpenSSL Management Committee announced on a blog post [118] that this patch set would not be adopted for 3.0 on the fear that the API would change over time. Finally more than one year after planned release of 3.0 which was still not coming, a team of volunteers from Akamai and Microsoft decided to fork the project as QuicTLS [119] and support these patches on top of the OpenSSL code in order to unblock QUIC development. This action was generally welcome by the community. Finally after OpenSSL 3.0 was finally released, the QUIC patch set was reconsidered and decided against, [120] causing tens to hundreds of reactions of disappointment among the community. [117] The pull request was closed, while users felt the need to publicly express their disappointment, [121] or beg operating system vendors to support the alternative QuicTLS fork, [122] [123] or seek for alternative solutions. [124] Finally Rich Salz, co-founder of the QuicTLS fork, announced [124] his interest in seeing an Apache project forked from QuicTLS. As of 25 February 2023 there is still no QUIC-compatible long-term supported TLS library available by default in operating systems without requiring end-users to rebuild it themselves from sources.

See also

Notes

  1. ↑ The major version 2.0.0 was skipped due to its previous use in the OpenSSL FIPS module. [29]

Related Research Articles

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network, such as the Internet. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

The Federal Information Processing Standard Publication 140-2,, is a U.S. government computer security standard used to approve cryptographic modules. The title is Security Requirements for Cryptographic Modules. Initial publication was on May 25, 2001, and was last updated December 3, 2002.

<span class="mw-page-title-main">GnuTLS</span> Free software library implementing TLS

GnuTLS is a free software implementation of the TLS, SSL and DTLS protocols. It offers an application programming interface (API) for applications to enable secure communication over the network transport layer, as well as interfaces to access X.509, PKCS #12, OpenPGP and other structures.

Datagram Transport Layer Security (DTLS) is a communications protocol providing security to datagram-based applications by allowing them to communicate in a way designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the stream-oriented Transport Layer Security (TLS) protocol and is intended to provide similar security guarantees. The DTLS protocol datagram preserves the semantics of the underlying transport—the application does not suffer from the delays associated with stream protocols, but because it uses User Datagram Protocol (UDP) or Stream Control Transmission Protocol (SCTP), the application has to deal with packet reordering, loss of datagram and data larger than the size of a datagram network packet. Because DTLS uses UDP or SCTP rather than TCP it avoids the TCP meltdown problem when being used to create a VPN tunnel.

<span class="mw-page-title-main">Network Security Services</span> Collection of cryptographic computer libraries

Network Security Services (NSS) is a collection of cryptographic computer libraries designed to support cross-platform development of security-enabled client and server applications with optional support for hardware TLS/SSL acceleration on the server side and hardware smart cards on the client side. NSS provides a complete open-source implementation of cryptographic libraries supporting Transport Layer Security (TLS) / Secure Sockets Layer (SSL) and S/MIME. NSS releases prior to version 3.14 are tri-licensed under the Mozilla Public License 1.1, the GNU General Public License, and the GNU Lesser General Public License. Since release 3.14, NSS releases are licensed under GPL-compatible Mozilla Public License 2.0.

Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. The extension allows a server to present one of multiple possible certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites to be served by the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. This also allows a proxy to forward client traffic to the right server during TLS/SSL handshake. The desired hostname is not encrypted in the original SNI extension, so an eavesdropper can see which site is being requested. The SNI extension was specified in 2003 in RFC 3546

In cryptography, Curve25519 is an elliptic curve used in elliptic-curve cryptography (ECC) offering 128 bits of security and designed for use with the Elliptic-curve Diffie–Hellman (ECDH) key agreement scheme. It is one of the fastest curves in ECC, and is not covered by any known patents. The reference implementation is public domain software.

Mbed TLS is an implementation of the TLS and SSL protocols and the respective cryptographic algorithms and support code required. It is distributed under the Apache License version 2.0. Stated on the website is that Mbed TLS aims to be "easy to understand, use, integrate and expand".

wolfSSL is a small, portable, embedded SSL/TLS library targeted for use by embedded systems developers. It is an open source implementation of TLS written in the C programming language. It includes SSL/TLS client libraries and an SSL/TLS server implementation as well as support for multiple APIs, including those defined by SSL and TLS. wolfSSL also includes an OpenSSL compatibility interface with the most commonly used OpenSSL functions.

Crypto++ is a free and open-source C++ class library of cryptographic algorithms and schemes written by Wei Dai. Crypto++ has been widely used in academia, student projects, open-source, and non-commercial projects, as well as businesses. Released in 1995, the library fully supports 32-bit and 64-bit architectures for many major operating systems and platforms, including Android, Apple, BSD, Cygwin, IBM AIX, Linux, MinGW, Solaris, Windows, Windows Phone and Windows RT. The project also supports compilation using C++03, C++11, C++14, and C++17 runtime libraries; and a variety of compilers and IDEs, including Borland Turbo C++, Borland C++ Builder, Clang, CodeWarrior Pro, GCC, Intel C++ Compiler (ICC), Microsoft Visual C/C++, and Sun Studio.

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.

In public-key cryptography, Edwards-curve Digital Signature Algorithm (EdDSA) is a digital signature scheme using a variant of Schnorr signature based on twisted Edwards curves. It is designed to be faster than existing digital signature schemes without sacrificing security. It was developed by a team including Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang. The reference implementation is public-domain software.

<span class="mw-page-title-main">Heartbleed</span> Security bug in OpenSSL

Heartbleed is a security bug in some outdated versions of the OpenSSL cryptography library, which is a widely used implementation of the Transport Layer Security (TLS) protocol. It was introduced into the software in 2012 and publicly disclosed in April 2014. Heartbleed could be exploited regardless of whether the vulnerable OpenSSL instance is running as a TLS server or client. It resulted from improper input validation in the implementation of the TLS heartbeat extension. Thus, the bug's name derived from heartbeat. The vulnerability was classified as a buffer over-read, a situation where more data can be read than should be allowed.

<span class="mw-page-title-main">LibreSSL</span> Open-source implementation of TLS protocols; forked from OpenSSL in 2014

LibreSSL is an open-source implementation of the Transport Layer Security (TLS) protocol. The implementation is named after Secure Sockets Layer (SSL), the deprecated predecessor of TLS, for which support was removed in release 2.3.0. The OpenBSD project forked LibreSSL from OpenSSL 1.0.1g in April 2014 as a response to the Heartbleed security vulnerability, with the goals of modernizing the codebase, improving security, and applying development best practices.

The tables below compare cryptography libraries that deal with cryptography algorithms and have application programming interface (API) function calls to each of the supported features.

POODLE is a security vulnerability which takes advantage of the fallback to SSL 3.0. If attackers successfully exploit this vulnerability, on average, they only need to make 256 SSL 3.0 requests to reveal one byte of encrypted messages. Bodo Möller, Thai Duong and Krzysztof Kotowicz from the Google Security Team discovered this vulnerability; they disclosed the vulnerability publicly on October 14, 2014. On December 8, 2014, a variation of the POODLE vulnerability that affected TLS was announced.

Let's Encrypt is a non-profit certificate authority run by Internet Security Research Group (ISRG) that provides X.509 certificates for Transport Layer Security (TLS) encryption at no charge. It is the world's largest certificate authority, used by more than 300 million websites, with the goal of all websites being secure and using HTTPS. The Internet Security Research Group (ISRG), the provider of the service, is a public benefit organization. Major sponsors include the Electronic Frontier Foundation (EFF), the Mozilla Foundation, OVH, Cisco Systems, Facebook, Google Chrome, Internet Society, AWS, NGINX, and Bill and Melinda Gates Foundation. Other partners include the certificate authority IdenTrust, the University of Michigan (U-M), and the Linux Foundation.

In cryptography, Curve448 or Curve448-Goldilocks is an elliptic curve potentially offering 224 bits of security and designed for use with the elliptic-curve Diffie–Hellman (ECDH) key agreement scheme.

ChaCha20-Poly1305 is an authenticated encryption with associated data (AEAD) algorithm, that combines the ChaCha20 stream cipher with the Poly1305 message authentication code. It has fast software performance, and without hardware acceleration, is usually faster than AES-GCM.

<span class="mw-page-title-main">Rustls</span> Open-source implementation of TLS in Rust

Rustls is an open-source implementation of the Transport Layer Security (TLS) cryptographic protocol written in the Rust programming language. TLS is essential to internet security, and Rustls aims to enable secure, fast TLS connections. Rustls uses Rust's enforcement of memory safety to reduce the risk of security vulnerabilities. It is part of efforts to improve internet security by replacing memory-unsafe software libraries, such as OpenSSL, with memory-safe alternatives.

References

  1. ↑ "OpenSSL 3.4.0". October 22, 2024. Retrieved October 22, 2024.
  2. ↑ "/source/license.html". www.openssl.org. Retrieved March 3, 2021.
  3. ↑ "OpenSSL License | Software Package Data Exchange (SPDX)". spdx.org.
  4. ↑ Laurie, Ben (January 6, 1999). "ANNOUNCE: OpenSSL (Take 2". ssl-users (Mailing list). Retrieved October 29, 2018.
  5. ↑ "New Committers". OpenSSL Software Foundation. May 20, 2019. Retrieved October 11, 2024.
  6. ↑ "OpenSSL Management Committee". OpenSSL Software Foundation. Retrieved November 3, 2019.
  7. ↑ "OpenSSL Committers". OpenSSL Software Foundation. Retrieved November 3, 2019.
  8. ↑ Marquess, Steve (January 19, 2017). "Akamai sponsors TLS 1.3". openssl-announce (Mailing list). Retrieved November 9, 2018.
  9. ↑ "OpenSSL – Changelog". OpenSSL Software Foundation. Retrieved September 26, 2016.
  10. ↑ "OpenSSL Releases". GitHub . Retrieved December 6, 2022.
  11. 1 2 "OpenSSL Library – Release Strategy". OpenSSL Software Foundation. Retrieved August 1, 2024.
  12. 1 2 3 4 5 6 7 8 "OpenSSL 0.9.x series notes". GitHub . Retrieved December 6, 2022.
  13. ↑ "OpenSSL 1.0.0 series notes". GitHub . Retrieved December 6, 2022.
  14. ↑ "OpenSSL 1.0.1 series notes". GitHub . Retrieved December 6, 2022.
  15. ↑ R. Seggelmann; M. Tuexen; M. Williams (February 2012). Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension. Internet Engineering Task Force. doi: 10.17487/RFC6520 . ISSN   2070-1721. RFC 6520.Proposed Standard. Updated by RFC  8447.
  16. ↑ E. Rescorla (January 2010). Keying Material Exporters for Transport Layer Security (TLS). Internet Engineering Task Force. doi: 10.17487/RFC5705 . ISSN   2070-1721. RFC 5705.Proposed Standard. Updated by RFC  8446 and 8447.
  17. ↑ D. McGrew; E. Rescorla (May 2010). Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP). Internet Engineering Task Force. doi: 10.17487/RFC5764 . ISSN   2070-1721. RFC 5764.Proposed Standard. Updated by RFC  7983 and 9443.
  18. ↑ "OpenSSL 1.0.2 series notes". GitHub . Retrieved December 6, 2022.
  19. ↑ "OpenSSL 1.1.0 series notes". GitHub . Retrieved December 6, 2022.
  20. ↑ J-P. Aumasson (October 2015). M-J. Saarinen (ed.). The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC). Independent Submission IETF. doi: 10.17487/RFC7693 . ISSN   2070-1721. RFC 7693.Informational.
  21. ↑ Y. Nir; A. Langley (June 2018). ChaCha20 and Poly1305 for IETF Protocols. Internet Research Task Force (IRTF). doi: 10.17487/RFC8439 . ISSN   2070-1721. RFC 8439.Informational. Obsoletes RFC  7539.
  22. 1 2 A. Langley; M. Hamburg; S. Turner (January 2016). Elliptic Curves for Security. Internet Engineering Task Force. doi: 10.17487/RFC7748 . ISSN   2070-1721. RFC 7748.Informational.
  23. 1 2 Caswell, Matt (September 11, 2018). "OpenSSL 1.1.1 Is Released". OpenSSL Blog. OpenSSL Foundation. Retrieved October 11, 2024.
  24. ↑ "OpenSSL 1.1.1 series notes". GitHub . Retrieved December 6, 2022.
  25. ↑ Caswell, Matt (February 8, 2018). "Using TLS1.3 With OpenSSL". OpenSSL Blog. OpenSSL Foundation. Retrieved October 11, 2024.
  26. ↑ B. Kaliski; A. Rusch; J. Johnsson; A. Rusch (November 2016). K. Moriarty (ed.). PKCS #1: RSA Cryptography Specifications Version 2.2. Internet Engineering Task Force (IETF). doi: 10.17487/RFC8017 . ISSN   2070-1721. RFC 8017.Informational. Obsoletes RFC  3447.
  27. 1 2 3 "OpenSSL 3.0 Has Been Released!". OpenSSL Blog. September 7, 2021. Retrieved October 11, 2024.
  28. ↑ "OpenSSL 3.0 series notes". GitHub . Retrieved December 6, 2022.
  29. 1 2 Matt Caswell (November 28, 2018). "The Holy Hand Grenade of Antioch". OpenSSL Blog. Retrieved October 11, 2024.
  30. ↑ "OpenSSL 3.1 Final Release". OpenSSL Blog. March 7, 2023. Retrieved October 11, 2024.
  31. ↑ "OpenSSL 3.1 series notes". GitHub . Retrieved March 15, 2023.
  32. ↑ "OpenSSL 3.2.0 Final Release". OpenSSL Blog. November 23, 2023. Retrieved October 11, 2024.
  33. ↑ "OpenSSL 3.2 series notes". GitHub . Retrieved November 24, 2023.
  34. ↑ A. Ghedini; V. Vasiliev (December 2020). TLS Certificate Compression. Internet Engineering Task Force (IETF). doi: 10.17487/RFC8879 . ISSN   2070-1721. RFC 8879.Proposed Standard.
  35. ↑ T. Pornin (August 2013). Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA). Independent Submission. doi: 10.17487/RFC6979 . ISSN   2070-1721. RFC 6979.Informational.
  36. ↑ J. Gilmore; S. Weiler; T. Kivinen (June 2014). P. Wouters; H. Tschofenig (eds.). Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). Internet Engineering Task Force. doi: 10.17487/RFC7250 . ISSN   2070-1721. RFC 7250.Proposed Standard.
  37. ↑ "OpenSSL 3.3 Final Release". OpenSSL Blog. April 10, 2024. Retrieved October 11, 2024.
  38. ↑ "OpenSSL 3.4 Final Release". OpenSSL Blog. October 22, 2024. Retrieved November 22, 2024.
  39. 1 2 3 "GOST engine OpenSSL 1.0.0 README". cvs.openssl.org. Archived from the original on April 15, 2013.
  40. ↑ "OpenSSL source code, directory crypto/whrlpool". GitHub . Retrieved August 29, 2017.
  41. ↑ "Protecting data for the long term with forward secrecy" . Retrieved November 5, 2012.
  42. ↑ "NIST recertifies open source encryption module". gcn.com. Archived from the original on October 10, 2007.
  43. ↑ "FIPS-140". openssl.org. Retrieved November 12, 2019.
  44. ↑ "OpenSSL User Guide for the OpenSSL FIPS Object Module v2.0" (PDF). openssl.org. March 14, 2017. Retrieved November 12, 2019.
  45. 1 2 "Update on 3.0 Development, FIPS and 1.0.2 EOL". OpenSSL Blog. November 7, 2019. Retrieved October 11, 2024.
  46. ↑ "Cryptographic Module Validation Program Certificate #1747". Computer Security Resource Center. October 11, 2016.
  47. ↑ "Cryptographic Module Validation Program Certificate #2398". Computer Security Resource Center. October 11, 2016.
  48. ↑ "Cryptographic Module Validation Program Certificate #2473". Computer Security Resource Center. October 11, 2016.
  49. ↑ "Cryptographic Module Validation Program search results". Computer Security Resource Center. October 11, 2016.
  50. ↑ "Cryptographic Module Validation Program search results". Computer Security Resource Center. October 11, 2016.
  51. ↑ Schneider, Troy K. (July 20, 2016). "Getting government approval of a more secure OpenSSL". GCN: Technology, Tools, and Tactics for Public Sector IT.
  52. ↑ Waterman, Shaun (July 21, 2016). "SafeLogic saves the day for feds' use of OpenSSL". FedScoop.
  53. ↑ Rashid, Fahmida Y. (July 26, 2016). "Reworked OpenSSL on track for government validation". InfoWorld.
  54. ↑ Wells, Joyce (August 3, 2017). "Oracle, SafeLogic and OpenSSL Join Forces to Update FIPS Module". Database Trends and Applications.
  55. ↑ Kerner, Sean Michael (August 4, 2017). "Oracle Joins SafeLogic to Develop FIPS Module for OpenSSL Security". eWeek.
  56. ↑ "OpenSSL 3.0 Alpha7 Release". OpenSSL Blog. October 20, 2020. Retrieved October 11, 2024.
  57. ↑ "Cryptographic Module Validation Program: OpenSSL". Computer Security Resource Center. October 11, 2016.
  58. ↑ "OpenSSL: Source, License". openssl.org.
  59. ↑ "Licenses – Free Software Foundation". fsf.org.
  60. ↑ "WGET 1.10.2 for Windows (win32)". users.ugent.be. Archived from the original on January 2, 2008.
  61. ↑ "Releases of source and binaries". climm.org. Archived from the original on February 12, 2011. Retrieved November 30, 2010.
  62. ↑ "Deluge LICENSE file". deluge-torrent.org. Retrieved January 24, 2013.
  63. ↑ Salz, Rich (August 1, 2015). "License Agreements and Changes Are Coming". openssl.org. Retrieved October 11, 2024.
  64. ↑ "OpenSSL Re-licensing to Apache License v. 2.0 To Encourage Broader Use with Other FOSS Projects and Products". March 23, 2017. Archived from the original on July 18, 2017. Retrieved August 6, 2018.
  65. ↑ Lee, Victoria; Radcliffe, Mark; Stevenson, Chris (5 February 2019). "Top 10 FOSS legal developments of 2018". Opensource.com, Red Hat . Archived from the original on 5 February 2019. Retrieved 28 September 2019. The OpenSSL project announced that it had completed its shift from the OpenSSL/SSLeay license to the Apache Software License version 2 (ASLv2).
  66. ↑ "OpenSSL 3.0 License Change". September 22, 2021. Retrieved September 24, 2021.
  67. ↑ "OpenSSL Updates Fix Critical Security Vulnerabilities". August 9, 2014. Retrieved August 25, 2014.
  68. ↑ "OpenSSL ASN.1 asn1_d2i_read_bio() Heap Overflow Vulnerability". Cisco.
  69. ↑ "ASN1 BIO vulnerability". OpenSSL.
  70. ↑ "On the Security of RC4 in TLS". Royal Holloway Department of Information Security.
  71. ↑ "research!rsc: Lessons from the Debian/OpenSSL Fiasco". research.swtch.com. Retrieved August 12, 2015.
  72. ↑ "SSLkeys". Debian Wiki. Retrieved June 19, 2015.
  73. ↑ "Debian OpenSSL – Predictable PRNG Bruteforce SSH Exploit Python". Exploits Database. June 1, 2008. Retrieved August 12, 2015.
  74. ↑ "DSA-1571-1 openssl – predictable random number generator". Debian Project. May 13, 2008.
  75. ↑ OpenSSL.org (April 7, 2014). "OpenSSL Security Advisory [07 Apr 2014]" . Retrieved April 9, 2014.
  76. ↑ OpenSSL (April 7, 2014). "TLS heartbeat read overrun (CVE-2014-0160)" . Retrieved April 8, 2014.
  77. ↑ Codenomicon Ltd (April 8, 2014). "Heartbleed Bug" . Retrieved April 8, 2014.
  78. ↑ "Why Heartbleed is dangerous? Exploiting CVE-2014-0160". IPSec.pl. 2014. Archived from the original on April 8, 2014. Retrieved April 8, 2014.
  79. ↑ Mutton, Paul (April 8, 2014). "Half a million widely trusted websites vulnerable to Heartbleed bug". Netcraft Ltd. Retrieved April 8, 2014.
  80. ↑ "OpenSSL continues to bleed out more flaws – more critical vulnerabilities found". Cyberoam Threat Research Labs. 2014. Archived from the original on June 19, 2014. Retrieved June 13, 2014.
  81. ↑ "CVE-2014-0224". CVE. 2014.
  82. ↑ "OpenSSL Security Advisory". OpenSSL. June 5, 2014.
  83. ↑ "OpenSSL Patches Severe Denial-of-Service Vulnerability". Brandon Stosh. March 20, 2015.
  84. ↑ Goodlin, Dan (January 28, 2016). "High-severity bug in OpenSSL allows attackers to decrypt HTTPS traffic". Ars Technica.
  85. ↑ "Agglomerated SSL". GitHub . September 7, 2010. Retrieved December 9, 2024.
  86. ↑ "security/assl: assl-1.5.0p0v0 – hide awful SSL API in a sane interface". OpenBSD ports . May 22, 2014. Retrieved February 10, 2015.
  87. ↑ "OpenBSD has started a massive strip-down and cleanup of OpenSSL". OpenBSD journal. April 15, 2014.
  88. ↑ "OpenBSD forks, prunes, fixes OpenSSL". ZDNet. April 21, 2014. Retrieved April 21, 2014.
  89. ↑ "BoringSSL". Git at Google.
  90. ↑ "Google unveils independent 'fork' of OpenSSL called 'BoringSSL'". Ars Technica. June 21, 2014.
  91. ↑ "BoringSSL". Adam Langley's Weblog. June 20, 2014.
  92. ↑ "BoringSSL wants to kill the excitement that led to Heartbleed". Sophos. June 24, 2014.
  93. ↑ Buchanan, Bill (August 30, 2018). "Goodbye OpenSSL, and Hello To Google Tink". Medium. Retrieved April 4, 2019.
  94. ↑ "AWS-LC is a general-purpose cryptographic library". GitHub . September 4, 2020. Retrieved December 8, 2024.
  95. ↑ "OpenSSL 3 breaks webpack build · Issue #22305 · brave/brave-browser". GitHub.
  96. ↑ "openssl version 3.0 in arch? / Newbie Corner / Arch Linux Forums". bbs.archlinux.org.
  97. ↑ "OpenSSL 3.0 transition plans". Ubuntu Community Hub. April 6, 2022.
  98. ↑ "OpenSSL 3.0 Compatibility · Issue #597 · nginx/unit". GitHub.
  99. ↑ "Our future with OpenSSL". Discussions on Python.org. November 28, 2022.
  100. ↑ "The experience of bringing OpenSSL 3.0 into Red Hat Enterprise Linux and Fedora". www.redhat.com.
  101. ↑ "Compile against OpenSSL 3.X". groups.google.com.
  102. ↑ "ESET Management Agent (RHEL 9.x, OpenSSL 3.0.x)". ESET Security Forum. June 6, 2022.
  103. ↑ "Issue 46313: SSLObject does not raise SSLEOFError on OpenSSL 3 - Python tracker". bugs.python.org.
  104. ↑ "RHEL 9 : openssl (RHSA-2022:6224)". www.tenable.com.
  105. ↑ "Massive performance degradation in OpenSsl 3.0 if used in a heavy multi threaded server application · Issue #17064 · openssl/openssl". GitHub.
  106. ↑ "Performance issue with Openssl 3.0 in multi threaded application when using d2i_x509 · Issue #17950 · openssl/openssl". GitHub.
  107. ↑ "Severe efficiency degradation of credential loading in comparison to 1.1.1 · Issue #18814 · openssl/openssl". GitHub.
  108. ↑ "3.0 performance degraded due to locking · Issue #20286 · openssl/openssl". GitHub.
  109. ↑ "High cpu usage for outbound ssl requests after upgrading from v16.15.0 to v18.1.0 · Issue #43128 · nodejs/node". GitHub.
  110. ↑ "Massive performance degradation in OpenSsl 3.0 FIPS provider · Issue #18472 · openssl/openssl". GitHub.
  111. ↑ "Performance measurements · Issue #16791 · openssl/openssl". GitHub.
  112. ↑ "PEM/DER decoding of PKCS8 RSA private keys are 80 times slower in 3.0 · Issue #15199 · openssl/openssl". GitHub.
  113. ↑ "3.0 Performance problems · Issue #17627 · openssl/openssl". GitHub.
  114. ↑ Thomson, Martin; Turner, Sean (January 14, 2017). "Using Transport Layer Security (TLS) to Secure QUIC" – via IETF.
  115. ↑ "221 - boringssl - A fork of OpenSSL that is designed to meet Google's needs - Monorail". bugs.chromium.org.
  116. ↑ "Support QUIC TLS API (#826) · Issues · gnutls / GnuTLS · GitLab". GitLab. September 4, 2019.
  117. 1 2 3 "WIP: master QUIC support by tmshort · Pull Request #8797 · openssl/openssl". GitHub.
  118. ↑ "QUIC and OpenSSL". OpenSSL Blog. February 17, 2020. Retrieved October 11, 2024.
  119. ↑ "quictls announce on twitter".
  120. ↑ "OMC Release Requirements". www.mail-archive.com.
  121. ↑ "The QUIC API OpenSSL will not provide | daniel.haxx.se". October 25, 2021.
  122. ↑ Tarreau, Willy (October 27, 2021). "[Pkg-openssl-devel] Any intent to maintain quictls ?".
  123. ↑ "Bug#1011391: openssl: please support quictls patchset". groups.google.com.
  124. 1 2 "HTTP/3 support · Issue #680 · haproxy/haproxy". GitHub.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.