OpenSSL

Revision as of 10:55, 7 May 2025 by imported>Xose.vazquez (→‎Forks)
(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)

Template:Short description Template:Distinguish Template:Use mdy dates {{#invoke:Infobox|infobox}}Template:Template other{{#invoke:Check for unknown parameters | check | showblankpositional=1 | unknown = Template:Main other | preview = Page using Template:Infobox software with unknown parameter "_VALUE_"|ignoreblank=y | AsOf | author | background | bodystyle | caption | collapsetext | collapsible | developer | discontinued | engine | engines | genre | included with | language | language count | language footnote | latest preview date | latest preview version | latest release date | latest release version | latest_preview_date | latest_preview_version | latest_release_date | latest_release_version | licence | license | logo | logo alt | logo caption | logo upright | logo size | logo title | logo_alt | logo_caption | logo_upright | logo_size | logo_title | middleware | module | name | operating system | operating_system | other_names | platform | programming language | programming_language | released | replaced_by | replaces | repo | screenshot | screenshot alt | screenshot upright | screenshot size | screenshot title | screenshot_alt | screenshot_upright | screenshot_size | screenshot_title | service_name | size | standard | title | ver layout | website | qid }}Template:Main other

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.

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 historyEdit

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.<ref>Template:Cite mailing list</ref>

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.

Template:As of,<ref name=new_omc_member>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> the OpenSSL management committee consisted of seven people<ref name=omc>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> and there are seventeen developers<ref name=committers>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> 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 US$1 million per year and relies primarily on donations. Development of TLS 1.3 was sponsored by Akamai.<ref>Template:Cite mailing list</ref>

Major version releasesEdit

citation
CitationClass=web

}}</ref><ref name=NEWS.md>{{#invoke:citation/CS1|citation

CitationClass=web

}}</ref>

Version Original release date citation CitationClass=web

}}</ref> !! Comment !! Last minor version

Template:Version<ref name=openssl_0.9.x_notes>{{#invoke:citation/CS1|citation CitationClass=web

}}</ref>

Template:Start date
  • Official start of the OpenSSL project
0.9.1c (23 December 1998)
Template:Version<ref name=openssl_0.9.x_notes /> Template:Start date
  • Successor of 0.9.1c
0.9.2b (6 April 1999)
Template:Version<ref name=openssl_0.9.x_notes /> Template:Start date
  • Successor of 0.9.2b
0.9.3a (27 May 1999)
Template:Version<ref name=openssl_0.9.x_notes /> Template:Start date
  • Successor of 0.9.3a
0.9.4 (9 August 1999)
Template:Version<ref name=openssl_0.9.x_notes /> Template:Start date
  • Successor of 0.9.4
0.9.5a (1 April 2000)
Template:Version<ref name=openssl_0.9.x_notes /> Template:Start date
  • Successor of 0.9.5a
0.9.6m (17 March 2004)
Template:Version<ref name=openssl_0.9.x_notes /> Template:Start date
  • Successor of 0.9.6m
0.9.7m (23 February 2007)
Template:Version<ref name=openssl_0.9.x_notes /> Template:Start date
  • Successor of 0.9.7m
0.9.8zh (3 December 2015)
Template:Version<ref name=openssl_1.0.0_notes>{{#invoke:citation/CS1|citation CitationClass=web

}}</ref>

Template:Start date
  • Successor of 0.9.8n
1.0.0t (Template:End date)
Template:Version<ref name=openssl_1.0.1_notes>{{#invoke:citation/CS1|citation CitationClass=web

}}</ref>

Template:Start date Template:End date 1.0.1u (Template:End date)
Template:Version<ref name=openssl_1.0.2_notes>{{#invoke:citation/CS1|citation CitationClass=web

}}</ref>

Template:Start date Template:End date 1.0.2u (Template:End date)
Template:Version<ref name=openssl_1.1.0_notes>{{#invoke:citation/CS1|citation CitationClass=web

}}</ref>

Template:Start date Template:End date 1.1.0l (Template:End date)
Template:Version<ref name=openssl_1.1.1_release_blog>{{#invoke:citation/CS1|citation CitationClass=web

}}</ref><ref name=openssl_1.1.1_notes>{{#invoke:citation/CS1|citation

CitationClass=web

}}</ref>

Template:Start date Template:End date (LTS)
  • Successor of 1.1.0i
  • Support for TLS 1.3<ref>{{#invoke:citation/CS1|citation
CitationClass=web

}}</ref><ref name=openssl_1.1.1_release_blog/>

1.1.1w (11 September 2023)
Template:Version<ref name=openssl_3.0.0_release_blog>{{#invoke:citation/CS1|citation CitationClass=web

}}</ref><ref name=openssl_3.0_notes>{{#invoke:citation/CS1|citation

CitationClass=web

}}</ref>
Template:Refn

Template:Start date Template:End date (LTS) CitationClass=web

}}</ref>

Ongoing development
Template:Version<ref name=openssl_3.1.0_release_blog>{{#invoke:citation/CS1|citation CitationClass=web

}}</ref><ref name=openssl_3.1_notes>{{#invoke:citation/CS1|citation

CitationClass=web

}}</ref>

Template:Start date Template:End date 3.1.8 (11 February 2025)
Template:Version<ref name=openssl_3.2.0_release_blog>{{#invoke:citation/CS1|citation CitationClass=web

}}</ref><ref name=openssl_3.2_notes>{{#invoke:citation/CS1|citation

CitationClass=web

}}</ref>

Template:Start date Template:End date Ongoing development
Template:Version<ref name=openssl_3.3_final_release>{{#invoke:citation/CS1|citation CitationClass=web

}}</ref>

Template:Start date Template:End date Ongoing development
Template:Version<ref name=openssl_3.4_final_release>{{#invoke:citation/CS1|citation CitationClass=web

}}</ref>

Template:Start date Template:End date Ongoing development
Template:Version<ref name=openssl_3.5_final_release>{{#invoke:citation/CS1|citation CitationClass=web

}}</ref>

Template:Start date Template:End date (LTS)
  • Support for PQC algorithms (ML-KEM, ML-DSA and SLH-DSA)
  • Support for server side QUIC (RFC 9000)
  • Support for 3rd party QUIC stacks including 0-RTT support
  • Support added for opaque symmetric key objects (EVP_SKEY)
  • A new configuration option no-tls-deprecated-ec to disable support for TLS groups deprecated in RFC8422
  • A new configuration option enable-fips-jitter to make the FIPS provider to use the JITTER seed source
  • Support for central key generation in CMP
  • Support for multiple TLS keyshares and improved TLS key establishment group configurability
  • API support for pipelining in provided cipher algorithms
Ongoing development
Template:Version

AlgorithmsEdit

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,<ref name="gost">{{#invoke:citation/CS1|citation

|CitationClass=web }}</ref> SM4

Cryptographic hash functions
MD5, MD4, MD2, SHA-1, SHA-2, SHA-3, RIPEMD-160, MDC-2, GOST R 34.11-94,<ref name="gost" /> BLAKE2, Whirlpool,<ref>{{#invoke:citation/CS1|citation

|CitationClass=web }}</ref> SM3

Public-key cryptography
RSA, DSA, Diffie–Hellman key exchange, Elliptic curve, X25519, Ed25519, X448, Ed448, GOST R 34.10-2001,<ref name="gost" /> SM2

(Perfect forward secrecy is supported using elliptic curve Diffie–Hellman since version 1.0.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>)

FIPS 140 validationEdit

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.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> 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.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> 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.<ref name="openssl_blog_3.0_update">{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> 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),<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> OpenSSL FIPS Object Module SE (certificate #2398),<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> and OpenSSL FIPS Object Module RE (certificate #2473).<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> 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<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> and CryptoComply from SafeLogic.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

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<ref>Template:Cite news</ref><ref>Template:Cite news</ref><ref>Template:Cite news</ref> and further support from Oracle in 2017,<ref>Template:Cite news</ref><ref>Template:Cite news</ref> but the process has been challenging.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

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.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

LicensingEdit

OpenSSL was dual-licensed under the OpenSSL License and the SSLeay License, which means that the terms of either licenses can be used.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> 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.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> 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.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> Some packages (like Deluge) explicitly modify the GPL license by adding an extra section at the beginning of the license documenting the exception.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> 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.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> This process commenced in March 2017,<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> and was complete in 2018.<ref name = "Various, Red Hat, 2019" >{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

On 7 September 2021, OpenSSL 3.0.0 was released under the Apache License 2.0.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

Notable vulnerabilitiesEdit

Denial of service: ASN.1 parsingEdit

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 vulnerabilityEdit

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 Template:CVE 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.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

ASN.1 BIO vulnerabilityEdit

When using Basic Input/Output (BIO)<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> 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 Template:CVE. 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.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

SSL, TLS and DTLS plaintext recovery attackEdit

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<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> on February 5, 2013. The vulnerability was assigned the CVE identifier Template:CVE.

Predictable private keys (Debian-specific)Edit

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.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> 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.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

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.<ref name="dsa-1571-1">{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

Template:AnchorHeartbleedEdit

{{#invoke:Labelled list hatnote|labelledList|Main article|Main articles|Main page|Main pages}}

File: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<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> (Template:CVE). By reading the memory of the web server, attackers could access sensitive data, including the server's private key.<ref name="hb">{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> 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.Template: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.<ref name="ipsec">{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

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.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> However, Heartbleed can affect both the server and client.

Template:AnchorCCS injection vulnerabilityEdit

The CCS Injection Vulnerability (Template:CVE) is a security bypass vulnerability that results from a weakness in OpenSSL methods used for keying material.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

This vulnerability can be exploited through the use of a man-in-the-middle attack,<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> 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.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

Template:AnchorClientHello sigalgs DoSEdit

This vulnerability (Template:CVE) 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.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

Template:AnchorKey recovery attack on Diffie–Hellman small subgroupsEdit

This vulnerability (Template:CVE) 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.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

ForksEdit

Template:AnchorAgglomerated SSLEdit

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),<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> which reuses OpenSSL API under the hood, but provides a much simpler external interface.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> It has since been deprecated in light of the LibreSSL fork circa 2015.

LibreSSLEdit

{{#invoke:Labelled list hatnote|labelledList|Main article|Main articles|Main page|Main pages}}

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.<ref name="fork">{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> In the first week of pruning the OpenSSL's codebase, more than 90,000 lines of C code had been removed from the fork.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

Template:AnchorBoringSSLEdit

In June 2014, Google announced its own fork of OpenSSL dubbed BoringSSL.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> Google plans to co-operate with OpenSSL and LibreSSL developers.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> Google has since developed a new library, Tink, based on BoringSSL.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

Template:AnchorAWS-LCEdit

In September 2020, it was released as a general-purpose cryptographic library maintained by the Amazon Web Services Cryptography team to be used in the AWS cloud computing platform. It іs based on code from the OpenSSL and BoringSSL projects.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

Template:AnchorQuicTLSEdit

It's a collaborative fork between Akamai and Microsoft, based on OpenSSL 3.3 release, and with some features and fixes cherry-picked from the current OpenSSL repo.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

CriticismsEdit

Backwards compatibilityEdit

Among developers communities, OpenSSL is often cited for introducing API compatibility breakage with each new major version,<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> which requires software adaptations that tend to delay new version adoptions.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> This, combined with the fact that previous releases are generally maintained for no more than two years after a new major one is released<ref name="openssl_3.0.0_release_blog" /> tends to force some vendors to anticipate software migrations very early while still having little time left<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> to update to a new release, sometimes at the risk of losing some compatibility with existing software<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> or risking regressions.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

Delay between releasesEdit

While long-term support (LTS) releases are maintained for 5 years,<ref name='releasestrat'/> 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<ref name="openssl_blog_3.0_update" /> and was finally issued 21 months later<ref name="openssl_3.0.0_release_blog" /> 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 regressionsEdit

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.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> The OpenSSL team has created a meta-issue to try to centralize reports of such massive performance regressions.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> 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' requirementsEdit

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,<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> and identified that some adaptations to TLS libraries would be needed. Such modifications were brought to BoringSSL<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> which was the library being primarily used by QUIC developers by then, and later ported to other libraries.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> A port of this work was quickly proposed to OpenSSL.<ref name="auto1">{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> While some discussion started the same day, it quickly stalled and was first blocked on license considerations,<ref name="auto1"/> then kept on hold once these concerns were cleared. Finally 10 months later the OpenSSL Management Committee announced on a blog post<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> 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<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> 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,<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> causing tens to hundreds of reactions of disappointment among the community.<ref name="auto1"/> The pull request was closed, while users felt the need to publicly express their disappointment,<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> or beg operating system vendors to support the alternative QuicTLS fork,<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> or seek for alternative solutions.<ref name="auto2">{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> Finally Rich Salz, co-founder of the QuicTLS fork, announced<ref name="auto2"/> 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 alsoEdit

Template:Portal

NotesEdit

Template:Reflist

ReferencesEdit

Template:Reflist

External linksEdit

Template:Sister project

|CitationClass=web }}

Template:Cryptographic software Template:SSL/TLS