OpenSSL

The main articles are:

• Cryptography
• SSL

2023

OpenSSL 3.1.0 with SSL/TLS implementation

After a year and a half of development, the OpenSSL 3.1.0 library was released with the implementation SSL of protocols/and TLS various. algorithms enciphering This became known on March 15, 2023. Support for OpenSSL 3.1 will be available until March 2025. Support for past OpenSSL 3.0 and 1.1.1 branches will last until September 2026 and September 2023, respectively. The project code is distributed under license Apache 2.0.

Major changes to OpenSSL 3.1.0:

• The FIPS module supports cryptographic algorithms that comply with the FIPS 140-3 security standard. Started the module certification process to obtain the FIPS 140-3 Certificate of Compliance. Until certification is complete after upgrading OpenSSL to branch 3.1, users can continue to use the FIPS module certified for FIPS 140-2. Among the changes in this version of the module, the inclusion of the Triple DES ECB, Triple DES CBC and EdDSA algorithms, which have not yet been tested for FIPS requirements, is noted. Also, in the new version, optimizations were made to improve performance and a transition was made to run internal tests every time the module was loaded, and not just after installation.
• The OSSL_LIB_CTX code has been redesigned. The updated version is eliminated from unnecessary locks and allows you to achieve higher performance.
• Improved performance of encoder and decoder frameworks.
• Performance optimization was performed related to the use of internal structures (hash tables) and caching.
• Faster generation of RSA keys in FIPS mode.
• For various processor architectures, specific assembler optimizations have been introduced into the implementation of AES-GCM, ChaCha20, SM3, SM4 and SM4-GCM algorithms. For example, the AES-GCM code is accelerated using AVX512 instructions vAES and vPCLMULQDQ.
• KBKDF (Key Based Key Derivation Function) has added support for the KMAC (KECCAK Message Authentication Code) algorithm.
• Various "OBJ_*" functions are adapted for use in multithreaded code.
• Added the ability to use the RNDR statement and RNDRRS registers available in processors based on the AArch64 architecture to generate pseudo-random numbers.
• Transferred to the category of outdated functions OPENSSL_LH_stats, OPENSSL_LH_node_stats, OPENSSL_LH_node_usage_stats, OPENSSL_LH_stats_bio, OPENSSL_LH_node_stats_bio and OPENSSL_LH_node_usage_stats_bio. The macro has been declared obsolete DEFINE_LHASH_OF^[1].

Troubleshooting Memory Disclosure Error

OpenSSL has fixed the memory disclosure error, you need to update the software as soon as possible. This became known on February 10, 2023.

A total of 8 vulnerabilities have been fixed that allowed attackers to perform malicious actions on compromised devices.

OpenSSL developers have released fixes for a number of vulnerabilities, including a serious error in the encryption toolkit. This error could potentially expose users to malicious attacks.

The vulnerability is CVE-2023-0286 related to the Type Confusion variety, which could allow an attacker to read memory content or cause a denial of service, "OpenSSL said in a statement.

In most cases, the attack requires the attacker to provide both a chain of certificates and a CRL, none of which must have a valid signature. If the attacker controls only one of these inputs, the other input must already contain the X.400 address as a CRL distribution point, they added to OpenSSL.

Errors associated with type confusion can have serious consequences, as they can be used to deliberately force a program to behave unintentionally, which can cause malicious code to crash or execute.

The problem has been fixed in OpenSSL 3.0.8, 1.1.1t and 1.0.2zg. Other vulnerabilities eliminated within the last updates include: CVE-2022-4203, CVE-2022-4304, CVE-2022-4450, CVE-2023-0215, CVE-2023-0216, CVE-2023-0217, CVE-2023-0401.

Successful exploitation of the above vulnerabilities can lead to application failure, disclosure of memory content, and even recovery of messages sent over the network in plain text^[2].

2022

Outdated version of OpenSSL in Dell, HP and Lenovo firmware puts supply chains at risk

Firmware analysis from Dell, HP and Lenovo revealed outdated versions of the OpenSSL cryptographic library, which poses additional risks to supply chains. This became known on November 28, 2022. Read more here.

Latest OpenSSL patches fix two vulnerabilities that are more dangerous than SSL Heartbleed

The latest OpenSSL patches have fixed two vulnerabilities that are more dangerous than SSL Heartbleed. This became known on July 7, 2022.

One of them was discovered by an ordinary Chinese student.

The first vulnerability, tracked as CVE-2022-2274, was discovered by a graduate student at Xidian University on June 22, 2022. In their latest post, the developers called CVE-2022-2274 a serious error in the implementation of RSA and confirmed that the vulnerability could be exploited to remotely execute malicious code on a computing device.

The second vulnerability, tracked as CVE-2022-2097, can lead to data leakage when encrypted using AES-OCB. In special instructions for AES acceleration from Intel, an error was made that when encrypting N data blocks performs a cycle not from 1 to N, but from 1 to N-1. This means that the last block of data will not be encrypted and will remain in its original form.

Both vulnerabilities have been fixed in the latest versions of OpenSSL, so the project developers recommend that users apply the released updates as soon as possible^[3].

QNAP warned of OpenSSL infinite loop vulnerability

Some network devices data storage () NAS the Taiwan of the company QNAP are subject to an infinite loop vulnerability cryptographic OpenSSL in the open source library. More. here

OpenSSL vulnerability could cause remote servers to crash

OpenSSL developers have released a fix for a dangerous vulnerability in their software library. Its exploitation allowed attackers to cause a denial of service (DoS) state when analyzing certificates. This became known on March 17, 2022.

Vulnerability (CVE-2022-0778) received a score of 7.5 on the CVSS scale and is associated with parsing a distorted certificate with invalid explicit elliptic curve parameters, which leads to the so-called "infinite cycle." The problem lies in a function called BN_mod_sqrt (), which is used to compute a modular square root.

Because certificate parsing occurs before certificate signing is verified, any process that parses an externally provided certificate can be subject to a denial-of-service attack. An infinite loop can also be achieved when analyzing the generated private keys, since they can contain explicit parameters of an elliptic curve, the OpenSSL bulletin says.

For March 2022, there is no evidence that the vulnerability was used in real attacks. The issue affects OpenSSL versions 1.0.2, 1.1.1, and 3.0 and was fixed in OpenSSL versions 1.0.2zd (for premium support customers), 1.1.1n, and 3.0.2. OpenSSL 1.1.0 is also vulnerable, but will not receive a fix due to the end of the support period^[4].

TLS Version 1.3 Availability

On March 14, 2022, the company Kryptonite"" announced that its specialists, together with employees of the company, "" CryptoCom completed the development of an open implementation of the protocol TLS version 1.3, which provides data protection using. the Russian cryptographic algorithms It is available as an extension for OpenSSL 1.1.1. More. here

OpenSSL 3.0 received LTS status

The OpenSSL project announced long-term support for the OpenSSL 3.0 cryptographic library branch, the release of updates for which will be formed within 5 years from the date of release, i.e. until September 7, 2026. The previous LTS-branch 1.1.1 will be maintained until September 11, 2023. This became known on March 4, 2022.

Illustration: govinfosecurity.com

Additionally, we can note the release by the OpenBSD project of a portable edition of the LibreSSL 3.5.0 package, within which the OpenSSL fork is developing, aimed at providing a higher level of security. Among the changes in the presented version, porting from OpenSSL support RFC 3779 (X.509 extensions for IP addresses and autonomous systems) and the Certificate Transparency mechanism (an independent public log of all issued and revoked certificates, which makes it possible to independently audit all changes and actions of certification centers, and allows you to immediately track any attempts to secretly create fake records). Significantly improved compatibility with OpenSSL 1.1 and uses identical cipher names for TLSv1.3 with OpenSSL. Many functions have been switched to calloc. A large portion of calls has been added to libssl and libcrypto.^[5]

2021

Addressed critical buffer overflow vulnerability

The OpenSSL project, which develops the cryptographic library of the same name, announced a fix for one critical and one medium-risk vulnerability in its program code. Information about this appeared on September 1, 2021.

The OpenSSL open library is used in many web servers and in most sites that support. HTTPS The vulnerability allows an attacker to cause a buffer overflow error: to do this, you need to submit an content encrypted algorithm SM2 to the decryption application; these data can overflow the allocated memory buffer - as a maximum, by 62 bytes; thus, the content of other data located behind this buffer can be changed, which in theory can lead to a change in the behavior of the application or its failure.

The location of the buffer depends on the application, but, as a rule, it is located in the heap - the data structure with which the dynamically distributed memory of the application is implemented.

The vulnerability, identified by an expert named John Ouyang, received the CVE-2021-3711 index. She was assigned a critical index - 9.8 points on the CVSS scale. This issue has been fixed in OpenSSL 1.1.1l.

"Buffer overflow is a very typical programming error that occurs everywhere and regularly in software developments of any level," explained Dmitry Kiryukhin, an information security expert at SEC Consult Services. "Another thing is that OpenSSL is an extremely common library, as a result of which the trivial" bug "turns into a problem for most of the Internet."

In addition, the developers of the OpenSSL project have fixed another, less dangerous vulnerability, designated as CVE-2021-3712. This "bug" allows you to disclose confidential memory contents (including private keys) or cause the application to crash.

The vulnerability affects versions 1.1.1-1.1.1k, as well as 1.0.2-1.0.2y; corrected in versions 1.1.1j and 1.0.2za, respectively.^[6]

MGM Multi-Line Encryption Integration in OpenSSL

The joint efforts CryptoCom of "" and Kryptonite"" based on OpenSSL 1.1.1 created an implementation with, open source covering all current the Russian algorithms enciphering and modes of their use. This was reported on June 16, 2021 at the Kryptonit NPK. More. here

2018

OpenSSL 1.1.1

On September 11, 2018, the OpenSSL Project announced the release of OpenSSL 1.1.1, the next version of the Long Term Support (LTS) library.

According to representatives of the organization, the most important feature that appeared in OpenSSL 1.1.1 is protocol TLS 1.3. Since OpenSSL 1.1.1 matches OpenSSL 1.1.0 over API and ABI, applications running the older version can upgrade to OpenSSL 1.1.1 and take full advantage of TLS 1.3.

OpenSSL 1.1.1 received a completely rewritten random number generator, support for several, cryptographic algorithms an improved mechanism for repelling attacks through third-party channels, support for the Maximum Fragment Length TLS extension and a STORE module that provides a single reader URI-based for repositories, certificates keys, revoked certificate lists (CRLs) and other objects. Algorithms enciphering include SHA3, SHA512/224, and SHA512/256, EdDSA, X448, multi-prime RSA, SM2, SM3, SM4, SipHash, and ARIA.

According to the OpenSSL Project, OpenSSL 1.1.1 will be supported for at least five years. Version 1.1.0 will receive one year of support starting September 11, 2018. Until recently, the 1.0.2 branch, which was an LTS release, will be fully supported until the end of 2018, and then until the end of 2019 it will receive only security updates.^[7]

Changes made to openssl encryption policies

According to the results of a meeting of the OpenSSL Management Committee (OMC) held in early 2018 in London, changes to encryption policies were announced. In particular, OpenSSL developers will disable unsecured configurations by default[2]^[8][9]].

OMC decided that it was necessary to add the ability to disable new algorithms during compilation, and new encryption algorithms should interact with OpenSSL only through the EVP (EnVeloPe Digital Library) API.

In the future, each new algorithm must be developed by a national or international standards body, and to activate ciphers at the TLS level, they must be indicated at runtime.

In addition to changes in encryption policies, other adjustments have also been made to the project. For example, it was decided to abandon the developer newsletter (openssl-dev). One of the reasons was the frequent coincidence of publications intended for developers and for users (openssl-users). In addition, OMC decided to make GitHub the main platform for discussing developments.

A separate newsletter (openssl-project) was created to discuss OpenSSL policies. Anyone can subscribe to the newsletter, but only OMC and developers can make publications. It is also planned to make new efforts to reduce the time for deleting old tasks and refactoring ^[10] the ^[11]

Now new releases of the project will be released every week on Tuesdays in the absence of dangerous vulnerabilities with known exploits.

2017: OpenSSL 1.0.2n

On December 7, 2017, the OpenSSL Project announced the release of the OpenSSL 1.0.2n update, which includes a fix for two vulnerabilities.

The problem in SSL was discovered by David Benjamin, a Google researcher, through the Google OSS-Fuzz service.

The vulnerability is CVE-2017-3737 related to the "error state" mechanism presented in OpenSSL 1.0.2b. If attempts to extend the protocol negotiation mode continue in the event of a fatal error, this mechanism causes an immediate failure. The problem is that when you call the SSL_read () or SSL_write () functions directly, the mechanism does not work properly.

If SSL read ()/SSL write () is subsequently called by the application for the same SSL object, the data will be transmitted unencrypted directly from the SSL/TLS write layer. OpenSSL Project

Since for the vulnerability to be successfully exploited, the target application must contain an error that causes SSL_read () or SSL_write () after a fatal error occurs, the vulnerability is marked as "medium danger."

The second vulnerability (CVE-2017-3738) is related to a buffer overflow and allows an attacker to gain access to communications protected using TLS. It is quite difficult to carry out an attack in practice, so the vulnerability is marked as "low danger." The problem affects the OpenSSL 1.0.2 and 1.1.0 branches. However, due to the low risk of vulnerability, the 1.1.0 branch did not receive an update. The problem will be fixed with the release of OpenSSL 1.1.0h at one time^[12] have been^[12].

OpenSSL 2.3.0

Starting from version 2.30, this standard presents Russian cryptographic algorithms. In order for tokens to be used in OpenSSL programs, LISSIE has developed a special lissi_engine to connect tokens through their native PKCS# 11 libraries for the 2.30 standard. This connection practically works for the eToken GOST, Rutoken EDS and SHIPKA libraries. Unlike the standard ENGINE ccgost, the lissi_engine itself does not perform any cryptographic operations, but serves only as an intermediary between the application program and the PKCS# 11 token library.

Since lissi_engine uses some experimental OpenSSL tools in its implementation, a special version of this system, LirSSL2, has been created for its work. The new software package is a further development of the traditions laid down in the well-known CIPF 'LirSSL' company "LISSIE."

Thus, the lissi_engine allows you to use the token in OpenSSL programs as a full-fledged key and certificate store. In this case, the function of generating a key pair by the token itself is provided without the possibility of extracting the private key. In addition, it is possible to save certificates, scroll and select objects, etc.

Unfortunately, many hardware tokens support the PKCS# 11 standard only partially, imposing significant implementation limitations. Moreover, the performance of hardware tokens is often not high enough. Therefore, LISSIE has developed a LirCryptoki2 library that quite fully implements support for the PKCS# 11 standard for software tokens.

As a result, the application program has the ability to load two instances of lissi_engine, one of which is associated with a hardware token and the other with a software token. Operations with key material on the hardware token are performed by the hardware token, and all others are performed by the software token. The use of such a combination ensures both the security of the key material and the high performance of performing those cryptographic operations that do not require access to the private key on the hardware token. At the same time, all operations are carried out through standard OpenSSL interfaces, which allows you to use many powerful and flexible high-level functions in application programs.

An important feature of the libraries of the LISSIE company is their cross-platform nature. Both lissi_engine and LirCryptoki2 work in both Windows and Linux, both in 32-bit and 64-bit configurations. Since standard OpenSSL tools themselves successfully function on many platforms, applications can also be developed cross-platform.

OpenSSL 1.0.0

The well-known OpenSSL software system provides ample opportunities for using various cryptographic algorithms in application programs. Starting from version 1.0.0, OpenSSL also supports Russian cryptographic algorithms (GOST 28147-89, GOST R34.11-94, GOST R34.10-2001).

Support for certain cryptographic algorithms is carried out in OpenSSL 1.0.0 using the so-called ENGINE - plugins dynamically connected to the application program. OpenSSL 1.0.0 has a special ENGINE ccgost, developed by CryptoCom to support Russian cryptographic algorithms.

One of the important issues solved in organizing information security is the method of storing cryptographic keys. In traditional OpenSSL programs, keys are stored in files encrypted with a password. This means that during the operation of the program, the key is decrypted and for some time is present in memory in clear text, which creates the possibility of its abduction.

A more reliable way to store key material is provided by hardware tokens that fundamentally do not give keys outside, but are themselves able to generate keys and perform cryptographic operations with them. To work with tokens, a special international standard PKCS# 11 (Cryptoki) has been created, which defines protocols and interfaces for the interaction of the program with tokens.

Notes