As a part of our mission to be more open and engaged with our community, OpenSSL is pleased to announce we will be attending the International Cryptographic Module Conference 2023 or ICMC 2023 in Ottawa, Canada this week. ICMC 23 is building on a decade of cybersecurity thought leadership as the industry faces widespread changes and emerging threats in commercial cryptography.

The OpenSSL Management Committee (OMC) represents the official voice of the project and is ultimately responsible for all decisions regarding management and strategic direction of the project.

You may have already seen the recent blog post about Mark Cox leaving the OMC.

Following on from that we are delighted to announce that Anton Arapov, our engineering manager, has now joined the OMC.

You can check our website for the full list of members.

OpenSSL 1.1.1 series has reached its End of Life (EOL). As such it will no longer receive publicly available security fixes.

We are pleased to announce the immediate availability of OpenSSL 3.2 Alpha 1. This release incorporates a number of new features, most notably:

• Client-side QUIC support, including support for multiple streams (RFC 9000)
• Certificate compression in TLS (RFC 8879), including support for zlib, zstd and Brotli
• Deterministic ECDSA (RFC 6979)
• Support for Ed25519ctx, Ed25519ph, Ed448 and Ed448ph (RFC 8032) in addition to existing support for Ed25519
• AES-GCM-SIV (RFC 8452)
• Argon2 (RFC 9106) and supporting thread pool functionality
• HPKE (RFC 9180)
• The ability to use raw public keys in TLS (RFC 7250)
• TCP Fast Open (RFC 7413) support, where supported by the OS
• Support for provider-based pluggable signature schemes in TLS, enabling third-party post-quantum algorithm providers to use these algorithms with TLS
• Support for Brainpool curves in TLS 1.3
• SM4-XTS
• Support for using the Windows system certificate store as a source of trusted root certificates. This is not yet enabled by default and must be activated using an environment variable. This is likely to become enabled by default in a future feature release.

This is the end of an era for OpenSSL with the last of the original founders of the project passing on the torch to the current leadership of the project for the next phase of its evolution.

OpenSSL is pleased to announce the imminent release of OpenSSL 3.2 Alpha 1 on the 7th September 2023.

As this will be an alpha release, it is intended for development and testing purposes. It represents the first step in our planned release of OpenSSL 3.2.

Depending on the outcome of the alpha process, we hope to make a beta release as soon as two weeks after Alpha 1 is released. When we do move to beta, this will represent a feature freeze. Therefore, no new feature PRs will be accepted into the 3.2 branch after this.

More details about OpenSSL 3.2 Alpha 1 will be made available at the time of the release.

At OpenSSL, we’re always learning and taking small steps, informed by both fresh ideas and the feedback we receive. Today, we’d like to share a couple of updates we hope will make things clearer and more collaborative for our community.

These updates are part of our effort to align more closely with, and live by, our Mission and Values.

Last week marked the public announcement of the Downfall vulnerability in Intel CPUs and the Inception vulnerability in AMD CPUs. Both of these are microarchitectural side-channel attacks allowing an attacker with unprivileged execution on the same physical core as a victim process to extract confidential information from that process.

This blog post provides information and advice for users of OpenSSL. Specifically, it provides information on how users of OpenSSL may be affected by these vulnerabilities, and advice for users of OpenSSL on mitigation strategies.

Downfall Attack against Intel CPUs

Firstly, it should be noted that while the Downfall vulnerability is demoed against OpenSSL, this is a highly general microarchitectural side-channel attack which can compromise the security of essentially any software and is not specific to OpenSSL (nor is it something we could mitigate with code changes). This is not a vulnerability in OpenSSL.

Affected processors

This attack affects a large number of Intel processors across multiple generations, including Skylake, Tiger Lake and those generations in between. Exact details of affected models can be confirmed on the Intel website.

Note: The table lists a number of different historic side-channel vulnerabilities; the “Gather Data Sampling” (CVE-2022-40982) column is the relevant column. “MCU” means a processor is affected and that a microcode update has been issued.

What this attack enables

If an attacker can obtain local (but unprivileged) execution on a machine with an affected CPU, and they are able to schedule that process on the same physical core as another process, and they are able to execute AVX instructions, you should assume they are able to obtain read access to any information stored within that process’s memory.

It should be stressed that this attack is entirely dependent on an adversary being able to execute code on the same physical system as a victim process; therefore, systems which only execute code installed by trusted parties are not at risk. However, virtual machines (in the absence of the mitigations advised below) are not an effective protection.

The requirement for executing on the same physical core as a victim process can be met either by OS context switching or via hyperthreading.

Because OpenSSL provides accelerated implementations of many cryptographic primitives using x86 SIMD instructions, if an attacker executes an attack using this vulnerability on a process performing cryptographic operations using OpenSSL, there is an elevated risk that the information they are able to extract will include cryptographic key material or plaintexts, as this material is likely to have been recently processed in the victim process using SIMD instructions. In other words, the risk to key material or other cryptographic material is particularly high.

However, this does not mean that other information stored in a process is not vulnerable to compromise and we would recommend that users assume that all information stored in a vulnerable process is accessible to an attacker. While there are potentially limitations to the exploitation techniques published, the qualifiers to any such limitations are sufficiently complex to be unable to make assurances in any particular area.

Recommended mitigation

The following mitigations are available:

• Intel have released microcode updates for affected CPUs and the best course of action to mitigate these vulnerabilities is to deploy these microcode updates as soon as possible.

• In the absence of the ability to deploy these microcode updates, an alternative mitigation is to disable the ability to use AVX instructions in any untrusted process. This will generally require an OS update; for example, a mitigation patch is now available for the Linux kernel which allows this to be configured. Disabling AVX may break applications which have been designed or compiled under the assumption that AVX is available.

  It should be emphasised that a victim process does not need to execute AVX instructions to be affected. Exploitation can only be mitigated by preventing an attacker process from executing AVX instructions.

The immediate indicated mitigation action is to install the microcode updates providing mitigation for this vulnerability provided by Intel, or system firmware updates incorporating those microcode updates provided by your system vendor. Further information on how to deploy these microcode updates is available below.

The disabling of AVX should be seen as a fallback mitigation where it is not feasible to deploy these microcode or system firmware updates.

The following are not effective mitigations:

• A victim process cannot render itself immune to exploitation by refraining from use of AVX instructions, or all SIMD instructions. While the Downfall vulnerability targets code which makes use of 128-bit or wider data accesses, this includes the standard x86 XSAVE instruction which OS kernels use to save and restore process context. Therefore, even if an application recompiled itself to avoid any use of any SIMD instruction whatsoever, the contents of its registers would be exposed to an attacker whenever a context switch occurs.

It may be possible to provide mitigation by scheduling untrusted processes on separate physical cores to trusted processes, however we would not recommend trying to adopt this as a mitigation strategy, as it requires users to accurately classify trusted and untrusted processes, and to correctly configure process scheduling affinity. It would be hard for users to verify that this has been configured correctly, and there is substantial risk of misconfiguration.

Tracking mitigation deployment

An OS update may provide an indication of whether your hardware is vulnerable or not, and whether updated microcode providing mitigation for the vulnerability has been loaded. These OS updates may also provide the ability to disable AVX where such microcode updates are not loaded, but this generally needs to be explicitly requested and is not enabled by default. Note that a kernel update by itself will not load the updated microcode. Information on how to configure and verify operation for Linux-based operating systems is available here.

It is advisable to use these status reporting facilities, where available, to verify correct deployment of mitigations for this vulnerability.

It can be valuable to install these OS updates even on systems which are not affected in order to get this status reporting, as this can ease confirming whether a system is affected or not.

Obtaining microcode updates

To deploy the microcode updates for affected processors provided by Intel, there are two options:

• Install a system firmware update which incorporates these microcode updates provided by your system vendor. These updates will automatically deploy the microcode update at boot time. This is the preferred option.

• Alternatively, if a firmware update is not available from your system vendor, you can install the Intel microcode update yourself using the procedures specific to your OS. Note that microcode updates need to be applied on every boot.

  Note also that it is generally advised to apply microcode updates as early as possible in the boot process.

You can confirm correct deployment of microcode using the mitigation status reporting mechanism provided by your (updated) OS, if your OS provides one, as discussed above.

Alternatively, you can verify the reported running microcode version numbers directly where your OS provides facilities to do so. Refer to the Intel bulletin for patched microcode version numbers.

Inception Attack against AMD CPUs

Although announced at the same time as the Downfall attack, this attack is a separate microarchitectural side-channel attack which is unrelated to Downfall and does not rely on AVX functionality.

This attack affects Zen 1, 2, 3 and 4.

What this attack enables

Similarly to the Downfall attack, successful exploitation of this vulnerability requires an attacker have local (though unprivileged) execution on an affected CPU. If an attacker is able to obtain local unprivileged execution on an affected system, you should assume they are able to obtain read access to any information stored in memory. For example, the attack can be used to obtain information stored in the kernel, or in other processes, or file contents cached in memory by the kernel.

It should be stressed that this attack is entirely dependent on an adversary being able to execute code on the same physical system as a victim process; therefore, systems which only execute code installed by trusted parties are not at risk. However, virtual machines (in the absence of the mitigations advised below) are not an effective protection.

Recommended mitigation

An OS update is always required (and always sufficient) to fully mitigate this vulnerability.

The immediate indicated mitigation action is to install the updates providing mitigation for this vulnerability provided by your OS vendor as soon as they become available.

Microcode updates

AMD has also released microcode updates for Zen 3 and 4. Installing these updates is not essential to effective mitigation of this vulnerability, as OS updates alone are capable of adequate mitigation. However, installing these updates may improve performance when mitigations for this vulnerability are enabled. In any case, installation of these updates is recommended.

These microcode updates are not needed for Zen 1 and 2.

Installing microcode updates alone does not provide adequate mitigation.

To reiterate, the indicated mitigation actions are as follows:

• Zen 1 and Zen 2: Install OS updates.
• Zen 3 and Zen 4: Install OS updates. If possible, deploy microcode updates (see below), though this is not required for full mitigation.

Tracking mitigation deployment

Once an OS update is installed, the update may be able to provide an indication of whether your hardware is vulnerable or not and, if so, whether mitigations are in place. Information on how to configure and verify operation for Linux-based operating systems is available here.

It is advisable to use these status reporting facilities, where available, to verify correct deployment of mitigations for this vulnerability.

For Linux, the “safe RET” and “IBPB” mitigation levels correspond to full mitigation of this vulnerability. All other mitigation levels provide only partial protection. The string “no microcode” will also appear in the status string if a microcode update is desirable but not present.

It can be valuable to install these OS updates even on systems which are not affected in order to get this status reporting, as this can ease confirming whether a system is affected or not.

Obtaining microcode updates for Zen 3 and 4

To deploy the microcode updates for Zen 3 and 4 provided by AMD, there are two options:

• Install a system firmware update which incorporates these microcode updates provided by your system vendor. These updates will automatically deploy the microcode update at boot time. This is the preferred option.

• Alternatively, if a firmware update is not available from your system vendor, you can install the AMD microcode update yourself using the procedures specific to your OS. Note that microcode updates need to be applied on every boot.

  Note also that it is generally advised to apply microcode updates as early as possible in the boot process.

You can confirm correct deployment of microcode using the mitigation status reporting mechanism provided by your (updated) OS, if your OS provides one, as discussed above.

Alternatively, you can verify the reported running microcode version numbers directly where your OS provides facilities to do so. Refer to the AMD bulletin for patched microcode version numbers.

We recently published our mission statement and values which included that our governance should be transparent. We’ve not really talked much about how we’re financed and where the money goes, so let’s make a start on changing that.

A little background for clarity: The OpenSSL project has two companies, registered in the USA.  The first, OpenSSL Software Foundation, is a non-profit organisation that is used to hold the copyrights, trademarks, as well as things like the contributor license agreements (CLA). The second, OpenSSL Software Services, is our commercial entity that provides companies with paid support and other services, and pays our consultants to work on those services as well as development on OpenSSL. The OpenSSL project relies on funding to maintain and improve OpenSSL, and the goal of OpenSSL Software Services is to ensure long term sustainable funding to the project.

The Heartbleed vulnerability in 2014 highlighted the lack of funding of OpenSSL. The Linux Foundation therefore started the Core Infrastructure Initiative (CII) to gather funding from organisations, and they paid for two full time people to work on OpenSSL for three years, as well as a security audit. While we were extremely grateful for this at a critical time in the project, we knew that this model, and the funding itself, was going to only be a short-term interim measure. We have experimented with different ways to generate revenue ourselves, such as by accepting contracts (or sponsors) for specific features, such as platform support and FIPS. While these are helpful, they didn’t lead to reliable sustainable revenue.

We have organisations sponsoring us, both large corporate sponsors and smaller donations via GitHub sponsors. These vary year to year, and at the time of publishing this blog we have one platinum sponsor, one gold, three silver, and three bronze. There are also some organisations that provide their services at no or reduced cost. This funding helps to maintain the hardware and infrastructure but isn’t sufficient or stable enough to hire people.

So since 2020, our main source of income is by selling support contracts. Companies can purchase a contract if they need technical help with OpenSSL or if they need access to support for older end of life versions such as OpenSSL 1.0.2. Another driver for taking out such contracts is FIPS, where companies may wish to have FIPS compliant products with OpenSSL by rebranding our OpenSSL 3 FIPS certificate.

At the time of writing this blog we have just over 70 active support contracts. This has increased significantly in the last year. We started with a much smaller number of contracts mostly from companies that were using OpenSSL 1.0.2 and looking to have a year or two of backported fixes and support while they transitioned to OpenSSL 3. This year we gained a number of contracts from companies looking to use OpenSSL 3 and needing a rebranded FIPS certificate. Currently we’re getting interest from companies looking for short-term transitional support as they move from OpenSSL 1.1.1 (which becomes end of life later this calendar year). The needs of our customers will change over time, and we have to keep making sure we deliver value to our customers year on year.

This funding allows us to pay for eight consultants (at the time of writing this blog) to work full time on OpenSSL on engineering, management, and administration. Given the increased number of contracts this year we expect more positions to open up and we have a further 3 or 4 positions we are currently conducting interviews for. We also have other usual expenses (such as legal, administrative), as well as larger expenses (such as for services relating to FIPS certification and travel for conferences and face to face meetings).

We’re really glad that we’ve been able to move to a model where the OpenSSL project has a sustainable income source for the near future, helping us deliver on our important mission and values, to give everyone access to security and privacy tools.

UPDATE: Please note this position has been filled.

Job Description

We are seeking a passionate, tech-savvy individual to act as a Community Engagement Leader for the OpenSSL project. The ideal candidate will be responsible for fostering and enhancing connections between various communities around OpenSSL, facilitating fruitful discussions, spreading awareness about the project, and driving engagement and contributions. An essential aspect of this role is alignment with our core values and mission, as we expect these principles to be reflected in your day-to-day professional activities. Beyond community engagement, this role also involves collecting and contributing valuable insights to the project’s roadmap, making it an integral part of the project’s continuous growth and improvement.

This is a remote position with travel required, approximately up to 15% of working time. Given the global nature of the project, we require flexibility in accommodating various time zones outside of conventional business hours. We are seeking candidates located specifically within the Europe and North America.

To apply please send your resume to jobs@openssl.org by 17th August 2023.

Applications will be reviewed on a rolling basis. Only candidates selected for interviews will be contacted.