OpenSSL

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

Not to be confused with OpenSSH.

OpenSSL
Developer(s)The OpenSSL Project
Initial release1998 (1998)
Stable release1.1.1i (December 8, 2020 (2020-12-08)[1]) [±]
Preview release3.0 Alpha 11 (28 January 2021 (2021-01-28)[2]) [±]
Repository
Written inC, assembly, Perl
TypeCryptography library
LicenseApache License 2.0[3]
Websitewww.openssl.org

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) and Microsoft Windows.

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]

As of May 2019,[5] the OpenSSL management committee consisted of 7 people[6] and there are 17 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 one million USD per year and relies primarily on donations. Development of TLS 1.3 is sponsored by Akamai.[8]

Major version releases
OpenSSL release history[9][10]
VersionOriginal release dateCommentLast minor version
Old version, no longer maintained: 0.9.1 December 23, 1998
  • Official start of the OpenSSL project
 0.9.1c (December 23, 1998)
Old version, no longer maintained: 0.9.2 March 22, 1999
  • Successor of 0.9.1c
 0.9.2b (April 6, 1999)
Old version, no longer maintained: 0.9.3 May 25, 1999
  • Successor of 0.9.2b
 0.9.3a (May 27, 1999)
Old version, no longer maintained: 0.9.4 August 9, 1999
  • Successor of 0.9.3a
 0.9.4 (August 9, 1999)
Old version, no longer maintained: 0.9.5 February 28, 2000
  • Successor of 0.9.4
 0.9.5a (April 1, 2000)
Old version, no longer maintained: 0.9.6 September 24, 2000
  • Successor of 0.9.5a
 0.9.6m (March 17, 2004)
Old version, no longer maintained: 0.9.7 December 31, 2002
  • Successor of 0.9.6m
 0.9.7m (February 23, 2007)
Old version, no longer maintained: 0.9.8 July 5, 2005
  • Successor of 0.9.7m
 0.9.8zh (December 3, 2015)
Old version, no longer maintained: 1.0.0 March 29, 2010
  • Successor of 0.9.8n
 1.0.0t (December 3, 2015)
Old version, no longer maintained: 1.0.1[11] March 14, 2012 1.0.1u (September 22, 2016)
Old version, no longer maintained: 1.0.2[12] January 22, 2015
  • Successor of 1.0.1
  • Supported until 2019-12-31 (Long Term Support)[13]
  • Suite B support for TLS 1.2 and DTLS 1.2
  • Support for DTLS 1.2
  • TLS automatic elliptic curve (EC) selection
  • API to set TLS supported signature algorithms and curves
  • SSL_CONF configuration API
  • TLS Brainpool support
  • ALPN support
  • CMS support for RSA-PSS, RSA-OAEP, ECDH and X9.42 DH
  • FIPS 140 support
 1.0.2u (20 December 2019 (2019-12-20))
Old version, no longer maintained: 1.1.0[14] 25 August 2016 (2016-08-25)
  • Successor of 1.0.2h
  • Supported until 2019-09-11[13]
  • Support for BLAKE2 (RFC 7693)
  • Support for ChaCha20-Poly1305 (RFC 7539)
  • Support for X25519 (RFC 7748)
  • 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 (2019-09-10))
Current stable version: 1.1.1[15] 11 September 2018 (2018-09-11) 1.1.1i (8 December 2020 (2020-12-08))
Future release: 3.0.0 N/A 3.0.0 Alpha 11 (28 January 2021 (2021-01-28))
Legend:
Old version
Older 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,[18] SM4
Cryptographic hash functions
MD5, MD4, MD2, SHA-1, SHA-2, SHA-3, RIPEMD-160, MDC-2, GOST R 34.11-94,[18] BLAKE2, Whirlpool,[19] SM3
Public-key cryptography
RSA, DSA, Diffie–Hellman key exchange, Elliptic curve, X25519, Ed25519, X448, Ed448, GOST R 34.10-2001,[18] SM2

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

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.[21] 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.[22][23] 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.[24] 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),[25] OpenSSL FIPS Object Module SE (certificate #2398),[26] and OpenSSL FIPS Object Module RE (certificate #2473).[27] 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[28] and CryptoComply from SafeLogic.[29]

As of October 2020, OpenSSL has no active FIPS 140 validation. The long-promised 3.0 architecture promises to restore FIPS mode and is planned to undergo FIPS 140-2 testing, but significant delays have thrown that plan into doubt. The effort was first kicked off in 2016 with support from SafeLogic[30][31][32] and further support from Oracle in 2017,[33][34] but the process has been extremely challenging.[35] FIPS 140-2 ends testing on September 21, 2021 and the OpenSSL Management Committee's appetite to revise their efforts to reflect FIPS 140-3 standards to address testing beyond that date is unknown. On October 20, 2020, the OpenSSL FIPS Provider 3.0 was added to the CMVP Implementation Under Test List, reflecting an official engagement with the testing lab and intent to proceed with a FIPS 140-2 validation.[36]

Licensing

OpenSSL is double licensed under the OpenSSL License and the SSLeay License, which means that the terms of both licenses apply.[37] The OpenSSL License is Apache License 1.0 and SSLeay License bears some similarity to a 4-clause BSD License.

As the OpenSSL License is 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.[38] 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.[39][40] Some packages (like Deluge) explicitly modify the GPL license by adding an extra section at the beginning of the license documenting the exception.[41] Other packages use the LGPL-licensed GnuTLS and MPL-licensed NSS, which both 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.[42] This process commenced in March 2017,[43] and was complete in 2018.[44]

Notable vulnerabilities

Timing attacks on RSA keys

On March 14, 2003, a timing attack on RSA keys was discovered, indicating a vulnerability within OpenSSL versions 0.9.7a and 0.9.6. This vulnerability was assigned the identifier CAN-2003-0147 by the Common Vulnerabilities and Exposures (CVE) project. RSA blinding was not turned on by default by OpenSSL, since it is not easily possible to when providing SSL or TLS using OpenSSL.

Denial of service: ASN.1 parsing

OpenSSL 0.9.6k had 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.[45]

ASN.1 BIO vulnerability

When using Basic Input/Output (BIO)[46] 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.[47]

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[48] 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.[49][50] 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.[51]

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

Heartbleed
Main article: Heartbleed
A logo representing the Heartbleed bug

OpenSSL versions 1.0.1 through 1.0.1f had 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[53][54] (CVE-2014-0160). By reading the memory of the web server, attackers could access sensitive data, including the server's private key.[55] 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. 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.[56]

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.[57] 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.[58]

This vulnerability can be exploited through the use of a man-in-the-middle attack,[59] 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.[60]

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 before the OpenSSL team where they patched the issue.

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

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

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), which reuses OpenSSL API under the hood, but provides a much simpler external interface.[63] It has since been deprecated in light of the LibreSSL fork circa 2016.

LibreSSL
Main article: 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.[64] In the first week of pruning the OpenSSL's codebase, more than 90,000 lines of C code had been removed from the fork.[65]

BoringSSL

In June 2014, Google announced its own fork of OpenSSL dubbed BoringSSL.[66] Google plans to co-operate with OpenSSL and LibreSSL developers.[67][68][69] Google has since developed a new library, Tink, based on BoringSSL.[70]

See also

References
  1. "OpenSSL: Newslog". Retrieved December 8, 2020.
  2. "OpenSSL: Newslog". Retrieved January 29, 2021.
  3. "Change license to the Apache License v2.0 · openssl/openssl@". GitHub.
  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 November 3, 2019.
  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 – Release Strategy". OpenSSL Software Foundation. Retrieved September 26, 2016.
  11. "OpenSSL 1.0.1 Series Release Notes". Archived from the original on January 20, 2015. Retrieved February 20, 2017.
  12. "OpenSSL 1.0.2 Series Release Notes". Retrieved February 20, 2017.
  13. "Release Strategy". www.openssl.org. OpenSSL Foundation. February 25, 2019.
  14. "OpenSSL 1.1.0 Series Release Notes". Retrieved February 20, 2017.
  15. Caswell, Matt (September 11, 2018). "OpenSSL 1.1.1 Is Released". www.openssl.org. OpenSSL Foundation.
  16. Caswell, Matt (February 8, 2018). "Using TLS1.3 With OpenSSL - OpenSSL Blog". www.openssl.org. OpenSSL Foundation.
  17. Matt Caswell (November 28, 2018). "The Holy Hand Grenade of Antioch". OpenSSL Blog. Retrieved October 7, 2019.
  18. "GOST engine OpenSSL 1.0.0 README". cvs.openssl.org. Archived from the original on April 15, 2013.
  19. "OpenSSL source code, directory crypto/whrlpool". Retrieved August 29, 2017.
  20. "Protecting data for the long term with forward secrecy". Retrieved November 5, 2012.
  21. "NIST recertifies open source encryption module". gcn.com. Archived from the original on October 10, 2007.
  22. "FIPS-140". openssl.org. Retrieved November 12, 2019.
  23. "OpenSSL User Guide for the OpenSSL FIPS Object Module v2.0" (PDF). openssl.org. March 14, 2017. Retrieved November 12, 2019.
  24. https://www.openssl.org/blog/blog/2019/11/07/3.0-update/
  25. https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/1747
  26. https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/2398
  27. https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/2473
  28. https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search?SearchMode=Advanced&Vendor=google&ModuleName=boringcrypto&Standard=140-2&CertificateStatus=Active&ValidationYear=0
  29. https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search?SearchMode=Advanced&Vendor=safelogic&ModuleName=cryptocomply&Standard=140-2&CertificateStatus=Active&ValidationYear=0
  30. https://gcn.com/articles/2016/07/20/openssl-fips
  31. https://www.fedscoop.com/openssl-us-government-safelogic-fips-140-2-2016/
  32. https://www.infoworld.com/article/3098868/reworked-openssl-on-track-for-government-validation.html
  33. https://www.dbta.com/Editorial/News-Flashes/Oracle-SafeLogic-and-OpenSSL-Join-Forces-to-Update-FIPS-Module-119707.aspx
  34. https://www.eweek.com/security/oracle-joins-safelogic-to-develop-fips-module-for-openssl-security
  35. https://www.openssl.org/blog/blog/2020/10/20/OpenSSL3.0Alpha7/
  36. https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Modules-In-Process/IUT-List
  37. "OpenSSL: Source, License". openssl.org.
  38. "Licenses – Free Software Foundation". fsf.org.
  39. "WGET 1.10.2 for Windows (win32)". users.ugent.be. Archived from the original on January 2, 2008.
  40. "Releases of source and binaries". climm.org. Archived from the original on February 12, 2011. Retrieved November 30, 2010.
  41. "Deluge LICENSE file". deluge-torrent.org. Retrieved January 24, 2013.
  42. Salz, Rich (August 1, 2015). "License Agreements and Changes Are Coming". openssl.org. Retrieved August 23, 2015.
  43. "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.
  44. Lee, Victoria; Radcliffe, Mark; Stevenson, Chirs (5 February 2019). "Top 10 FOSS legal developments of 2018". Opensource.com, Red Hat. Archived from the original (html) 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).
  45. "OpenSSL Updates Fix Critical Security Vulnerabilities". August 9, 2014. Retrieved August 25, 2014.
  46. "OpenSSL ASN.1 asn1_d2i_read_bio() Heap Overflow Vulnerability". Cisco.
  47. "ASN1 BIO vulnerability". OpenSSL.
  48. "On the Security of RC4 in TLS". Royal Holloway Department of Information Security.
  49. "research!rsc: Lessons from the Debian/OpenSSL Fiasco". research.swtch.com. Retrieved August 12, 2015.
  50. "SSLkeys". Debian Wiki. Retrieved June 19, 2015.
  51. "Debian OpenSSL – Predictable PRNG Bruteforce SSH Exploit Python". Exploits Database. June 1, 2008. Retrieved August 12, 2015.
  52. "DSA-1571-1 openssl – predictable random number generator". Debian Project. May 13, 2008.
  53. OpenSSL.org (April 7, 2014). "OpenSSL Security Advisory [07 Apr 2014]". Retrieved April 9, 2014.
  54. OpenSSL (April 7, 2014). "TLS heartbeat read overrun (CVE-2014-0160)". Retrieved April 8, 2014.
  55. Codenomicon Ltd (April 8, 2014). "Heartbleed Bug". Retrieved April 8, 2014.
  56. "Why Heartbleed is dangerous? Exploiting CVE-2014-0160". IPSec.pl. 2014. Archived from the original on April 8, 2014. Retrieved April 8, 2014.
  57. Mutton, Paul (April 8, 2014). "Half a million widely trusted websites vulnerable to Heartbleed bug". Netcraft Ltd. Retrieved April 8, 2014.
  58. "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.
  59. "CVE-2014-0224". CVE. 2014.
  60. "OpenSSL Security Advisory". OpenSSL. June 5, 2014.
  61. "OpenSSL Patches Severe Denial-of-Service Vulnerability". Brandon Stosh. March 20, 2015.
  62. Goodlin, Dan (January 28, 2016). "High-severity bug in OpenSSL allows attackers to decrypt HTTPS traffic". Ars Technica.
  63. "security/assl: assl-1.5.0p0v0 – hide awful SSL API in a sane interface". OpenBSD ports. May 22, 2014. Retrieved February 10, 2015.
  64. "OpenBSD has started a massive strip-down and cleanup of OpenSSL". OpenBSD journal. April 15, 2014.
  65. "OpenBSD forks, prunes, fixes OpenSSL". ZDNet. April 21, 2014. Retrieved April 21, 2014.
  66. "BoringSSL". Git at Google.
  67. "Google unveils independent 'fork' of OpenSSL called 'BoringSSL'". Ars Technica. June 21, 2014.
  68. "BoringSSL". Adam Langley's Weblog. June 20, 2014.
  69. "BoringSSL wants to kill the excitement that led to Heartbleed". Sophos. June 24, 2014.
  70. Buchanan, Bill (August 30, 2018). "Goodbye OpenSSL, and Hello To Google Tink". Medium. Retrieved April 4, 2019.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.