From ad9a48c800f3b2fe9bf636db0fdf881e0771b5df Mon Sep 17 00:00:00 2001 From: Yaroslav Zhuravlev Date: Tue, 10 Jun 2025 15:41:34 +0100 Subject: [PATCH 1/6] Removed html, added directive formatting. --- content/nginx/fips-compliance-nginx-plus.md | 46 ++++++++++----------- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/content/nginx/fips-compliance-nginx-plus.md b/content/nginx/fips-compliance-nginx-plus.md index eb11c2b91..222e913d5 100644 --- a/content/nginx/fips-compliance-nginx-plus.md +++ b/content/nginx/fips-compliance-nginx-plus.md @@ -8,22 +8,22 @@ type: - concept --- -When used with a FIPS 140-2 validated build of OpenSSL operating in FIPS mode, NGINX Plus is compliant with the requirements of FIPS 140-2 (Level 1) with respect to the decryption and encryption of SSL/TLS‑encrypted network traffic. +When used with a FIPS 140-2 validated build of OpenSSL operating in FIPS mode, NGINX Plus is compliant with the requirements of FIPS 140-2 (Level 1) with respect to the decryption and encryption of SSL/TLS‑encrypted network traffic. ## Introduction -[FIPS 140-2](https://csrc.nist.gov/publications/detail/fips/140/2/final) is a United States Federal Standard that relates to the integrity and security of cryptographic modules. FIPS 140-2 Level 1 relates specifically to software cryptographic modules and makes stipulations about the cryptographic algorithms that may be used and the self‑tests that must be conducted to verify their integrity. +[FIPS 140-2](https://csrc.nist.gov/publications/detail/fips/140/2/final) is a United States Federal Standard that relates to the integrity and security of cryptographic modules. FIPS 140-2 Level 1 relates specifically to software cryptographic modules and makes stipulations about the cryptographic algorithms that may be used and the self‑tests that must be conducted to verify their integrity. -Several operating system vendors have obtained FIPS 140-2 Level 1 validation for the OpenSSL Cryptographic Module shipped with their respective operating systems: +Several operating system vendors have obtained FIPS 140-2 Level 1 validation for the OpenSSL Cryptographic Module shipped with their respective operating systems: - [Canonical Ltd.: Ubuntu 18.04 OpenSSL Cryptographic Module](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4540) - [Oracle Corporation: Oracle OpenSSL FIPS Provider](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4506) - [Red Hat, Inc.: Red Hat Enterprise Linux 7 NSS Cryptographic Module](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4498) - [SUSE, LLC: SUSE Linux Enterprise Server Kernel Crypto API Cryptographic Module](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4508) -NGINX Plus uses the OpenSSL cryptographic module exclusively for all operations relating to the decryption and encryption of SSL/TLS and HTTP/2 traffic. +NGINX Plus uses the OpenSSL cryptographic module exclusively for all operations relating to the decryption and encryption of SSL/TLS and HTTP/2 traffic. -When NGINX Plus is executed on an operating system where a FIPS‑validated OpenSSL cryptographic module is present and FIPS mode is enabled, NGINX Plus is compliant with FIPS 140-2 with respect to the decryption and encryption of SSL/TLS and HTTP/2 traffic. +When NGINX Plus is executed on an operating system where a FIPS‑validated OpenSSL cryptographic module is present and FIPS mode is enabled, NGINX Plus is compliant with FIPS 140-2 with respect to the decryption and encryption of SSL/TLS and HTTP/2 traffic. ## Definition of Terms @@ -31,25 +31,25 @@ This statement uses the following terms: - **Cryptographic module**: The OpenSSL software, comprised of libraries of FIPS‑validated algorithms that can be used by other applications. -- **Cryptographic boundary**: The operational functions that use FIPS‑validated algorithms. For NGINX Plus, the cryptographic boundary includes all functionality that is implemented by the [http_ssl](http://nginx.org/en/docs/http/ngx_http_ssl_module.html), [http_v2](http://nginx.org/en/docs/http/ngx_http_v2_module.html), [stream_ssl](http://nginx.org/en/docs/stream/ngx_stream_ssl_module.html), [mail_ssl](http://nginx.org/en/docs/mail/ngx_mail_ssl_module.html), and [http_auth_jwt](http://nginx.org/en/docs/http/ngx_http_auth_jwt_module.html) modules. These modules implement SSL and TLS operations for inbound and outbound connections which use HTTP, HTTP/2, TCP, and mail protocols. +- **Cryptographic boundary**: The operational functions that use FIPS‑validated algorithms. For NGINX Plus, the cryptographic boundary includes all functionality that is implemented by the [`http_ssl`](http://nginx.org/en/docs/http/ngx_http_ssl_module.html), [`http_v2`](http://nginx.org/en/docs/http/ngx_http_v2_module.html), [`stream_ssl`](http://nginx.org/en/docs/stream/ngx_stream_ssl_module.html), [`mail_ssl`](http://nginx.org/en/docs/mail/ngx_mail_ssl_module.html), and [`http_auth_jwt`](http://nginx.org/en/docs/http/ngx_http_auth_jwt_module.html) modules. These modules implement SSL and TLS operations for inbound and outbound connections which use HTTP, HTTP/2, TCP, and mail protocols. -- **NGINX Plus**: The NGINX Plus software application developed by NGINX, Inc. and delivered in binary format from NGINX servers. +- **NGINX Plus**: The NGINX Plus software application developed by NGINX, Inc. and delivered in binary format from NGINX servers. -- **FIPS mode**: When the operating system is configured to run in FIPS mode, the OpenSSL cryptographic module operates in a mode that has been validated to be in compliance with FIPS 140-2 Level 2. Most operating systems do not run in FIPS mode by default, so explicit configuration is necessary to enable FIPS mode. +- **FIPS mode**: When the operating system is configured to run in FIPS mode, the OpenSSL cryptographic module operates in a mode that has been validated to be in compliance with FIPS 140-2 Level 2. Most operating systems do not run in FIPS mode by default, so explicit configuration is necessary to enable FIPS mode. - **FIPS validated**: A component of the OpenSSL cryptographic module (the OpenSSL FIPS Object Module) is formally validated by an authorized certification laboratory. The validation holds if the module is built from source with no modifications to the source or build process. The implementation of FIPS mode that is present in operating system vendors’ distributions of OpenSSL contains this validated module. -- **FIPS compliant**: NGINX Plus is compliant with FIPS 140-2 Level 1 within the cryptographic boundary when used with a FIPS‑validated OpenSSL cryptographic module on an operating system running in FIPS mode. +- **FIPS compliant**: NGINX Plus is compliant with FIPS 140-2 Level 1 within the cryptographic boundary when used with a FIPS‑validated OpenSSL cryptographic module on an operating system running in FIPS mode. -## Verification of Correct Operation of NGINX Plus +## Verification of Correct Operation of NGINX Plus -The following process describes how to deploy NGINX Plus in a FIPS‑compliant fashion and then verify that the FIPS operations are correctly performed. +The following process describes how to deploy NGINX Plus in a FIPS‑compliant fashion and then verify that the FIPS operations are correctly performed. -The process uses Red Hat Enterprise Linux (RHEL) version 7.4 as an example, and can be adapted for other Linux operating systems that can be configured in FIPS mode. +The process uses Red Hat Enterprise Linux (RHEL) version 7.4 as an example, and can be adapted for other Linux operating systems that can be configured in FIPS mode. ### Step 1: Configure the Operating System to Use FIPS Mode -For the purposes of the following demonstration, we installed and configured a RHEL 7.4 server. The [Red Hat FIPS documentation](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/chap-federal_standards_and_regulations#sec-Enabling-FIPS-Mode) explains how to switch the operating system between FIPS mode and non‑FIPS mode by editing the boot options and restarting the system. +For the purposes of the following demonstration, we installed and configured a RHEL 7.4 server. The [Red Hat FIPS documentation](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/chap-federal_standards_and_regulations#sec-Enabling-FIPS-Mode) explains how to switch the operating system between FIPS mode and non‑FIPS mode by editing the boot options and restarting the system. For instructions for enabling FIPS mode on other FIPS‑compliant Linux operating systems, see the operating system documentation (for example, [Oracle Linux](https://docs.oracle.com/cd/E52668_01/E54670/html/ol7-fips-enable.html), [Ubuntu](https://ubuntu.com/security/certifications/docs/fips-faq)). @@ -86,11 +86,11 @@ openssl md5 /dev/null MD5(/dev/null)= d41d8cd98f00b204e9800998ecf8427e ``` -### Step 3: Install NGINX Plus on the Operating System +### Step 3: Install NGINX Plus on the Operating System -Follow the [F5 NGINX documentation](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-plus/) to install NGINX Plus on the host operating system, either directly from the [NGINX Plus repository](https://account.f5.com/myf5), or by downloading the **nginx-plus** package (**rpm** or **deb** package) onto another system and manually installing it on the host operating system. +Follow the [F5 NGINX documentation](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-plus/) to install NGINX Plus on the host operating system, either directly from the [NGINX Plus repository](https://account.f5.com/myf5), or by downloading the **nginx-plus** package (**rpm** or **deb** package) onto another system and manually installing it on the host operating system. -**Verify that NGINX Plus is correctly installed**: Run the following command to confirm that NGINX Plus is installed and is using the expected OpenSSL cryptographic module: +**Verify that NGINX Plus is correctly installed**: Run the following command to confirm that NGINX Plus is installed and is using the expected OpenSSL cryptographic module: ```shell nginx -V @@ -101,7 +101,7 @@ built with OpenSSL 1.0.2k-fips 26 Jan 2017 Observe that the version number of the OpenSSL library includes the `–fips` suffix. This indicates that the library is FIPS‑validated, but does not confirm that it is running in FIPS mode. -**Configure NGINX Plus to serve a simple SSL/TLS‑protected website**: Add the following simple configuration to NGINX Plus: +**Configure NGINX Plus to serve a simple SSL/TLS‑protected website**: Add the following simple configuration to NGINX Plus: ```nginx server { @@ -144,7 +144,7 @@ FIPS 140-2 disallows the use of some cryptographic algorithms, including the Cam (echo "GET /" ; sleep 1) | openssl s_client -connect :443 -cipher RC4-MD5 ``` -This cipher is insecure and is disabled by NGINX Plus by default. The SSL handshake always fails. +This cipher is insecure and is disabled by NGINX Plus by default. The SSL handshake always fails. #### CAMELLIA-SHA @@ -162,13 +162,13 @@ Note that if you attempt to issue the client request on a host running in FIPS m (echo "GET /" ; sleep 1) | openssl s_client -connect :443 -cipher AES256-SHA ``` -This cipher is considered secure by NGINX Plus and is permitted by FIPS 140-2. The SSL handshake succeeds. +This cipher is considered secure by NGINX Plus and is permitted by FIPS 140-2. The SSL handshake succeeds. ## Which Ciphers Are Disabled in FIPS Mode? The FIPS 140-2 standard only permits a [subset of the typical SSL and TLS ciphers](https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402annexa.pdf). -In the following test, the ciphers presented by NGINX Plus are surveyed using the [Qualys SSL server test](https://www.ssllabs.com/ssltest). In its default configuration, with the `ssl_ciphers HIGH:!aNULL:!MD5` directive, NGINX Plus presents the following ciphers to SSL/TLS clients: +In the following test, the ciphers presented by NGINX Plus are surveyed using the [Qualys SSL server test](https://www.ssllabs.com/ssltest). In its default configuration, with the `ssl_ciphers HIGH:!aNULL:!MD5` directive, NGINX Plus presents the following ciphers to SSL/TLS clients: Ciphers presented by NGINX Plus to clients when in non-FIPS mode @@ -176,7 +176,7 @@ When FIPS mode is enabled on the host operating system, the two ciphers that use Ciphers presented by NGINX Plus to clients when in FIPS mode -When you configure NGINX Plus with the `ssl_ciphers ALL` directive, NGINX Plus presents all the relevant ciphers available in the OpenSSL cryptographic module to the client. FIPS mode disables the following ciphers: +When you configure NGINX Plus with the `ssl_ciphers ALL` directive, NGINX Plus presents all the relevant ciphers available in the OpenSSL cryptographic module to the client. FIPS mode disables the following ciphers: - `TLS_ECDH_anon_WITH_RC4_128_SHA` - `TLS_ECDHE_RSA_WITH_RC4_128_SHA` @@ -189,8 +189,8 @@ When you configure NGINX Plus with the `ssl_ciphers ALL` directive, NGINX Plus ## Conclusion -NGINX Plus can be used to decrypt and encrypt SSL/TLS‑encrypted network traffic in deployments that require FIPS 140-2 Level 1 compliance. +NGINX Plus can be used to decrypt and encrypt SSL/TLS‑encrypted network traffic in deployments that require FIPS 140-2 Level 1 compliance. -The process described above may be used to verify that NGINX Plus is operating in conformance with the FIPS 140-2 Level 1 standard. +The process described above may be used to verify that NGINX Plus is operating in conformance with the FIPS 140-2 Level 1 standard. From 80e531b59f1188271bd36397abd71f24c6c7c1e4 Mon Sep 17 00:00:00 2001 From: Yaroslav Zhuravlev Date: Tue, 10 Jun 2025 15:42:58 +0100 Subject: [PATCH 2/6] FIPS: reworked to match FIPS140-3, rhel9, added extra info. --- content/nginx/fips-compliance-nginx-plus.md | 269 +++++++++++++++++--- 1 file changed, 230 insertions(+), 39 deletions(-) diff --git a/content/nginx/fips-compliance-nginx-plus.md b/content/nginx/fips-compliance-nginx-plus.md index 222e913d5..54a7a16d1 100644 --- a/content/nginx/fips-compliance-nginx-plus.md +++ b/content/nginx/fips-compliance-nginx-plus.md @@ -8,98 +8,246 @@ type: - concept --- -When used with a FIPS 140-2 validated build of OpenSSL operating in FIPS mode, NGINX Plus is compliant with the requirements of FIPS 140-2 (Level 1) with respect to the decryption and encryption of SSL/TLS‑encrypted network traffic. +## What is FIPS -## Introduction +The Federal Information Processing Standard (FIPS), issued by the [U.S. National Institute of Standards and Technology](https://www.nist.gov/) (NIST), defines mandatory security requirements for cryptographic modules used in federal IT systems. [FIPS 140-2](https://csrc.nist.gov/pubs/fips/140-2/upd2/final), and its successor [FIPS 140-3](https://csrc.nist.gov/pubs/fips/140-3/final), establish strict standards to protect sensitive but unclassified information, including government communications and citizen data. -[FIPS 140-2](https://csrc.nist.gov/publications/detail/fips/140/2/final) is a United States Federal Standard that relates to the integrity and security of cryptographic modules. FIPS 140-2 Level 1 relates specifically to software cryptographic modules and makes stipulations about the cryptographic algorithms that may be used and the self‑tests that must be conducted to verify their integrity. -Several operating system vendors have obtained FIPS 140-2 Level 1 validation for the OpenSSL Cryptographic Module shipped with their respective operating systems: +## Why FIPS Compliance Matters -- [Canonical Ltd.: Ubuntu 18.04 OpenSSL Cryptographic Module](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4540) -- [Oracle Corporation: Oracle OpenSSL FIPS Provider](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4506) -- [Red Hat, Inc.: Red Hat Enterprise Linux 7 NSS Cryptographic Module](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4498) -- [SUSE, LLC: SUSE Linux Enterprise Server Kernel Crypto API Cryptographic Module](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4508) +U.S. federal agencies and their contractors must use FIPS-validated cryptographic modules for systems supporting government operations. -NGINX Plus uses the OpenSSL cryptographic module exclusively for all operations relating to the decryption and encryption of SSL/TLS and HTTP/2 traffic. +Non-compliance can lead to contract loss, restricted project access, or fines. In recent years, enforcement of FIPS compliance has increased significantly across regulated industries. +At worst, it can lead to theft of personal information or national security documents. -When NGINX Plus is executed on an operating system where a FIPS‑validated OpenSSL cryptographic module is present and FIPS mode is enabled, NGINX Plus is compliant with FIPS 140-2 with respect to the decryption and encryption of SSL/TLS and HTTP/2 traffic. +Many federal programs and regulations mandate FIPS 140 validation, which serves as a foundation for safeguarding sensitive data in various industries. -## Definition of Terms +### FIPS Compliance Across U.S. Programs, Regulations, and Industries -This statement uses the following terms: +{{}} +| **Program/Regulation/Industry** | **FIPS 140-2/140-3 Requirement** | **Current Status** | +|-----------------------------------|---------------------------------------------|------------------------------------------------------------------------------------------------------| +| FISMA | 140-2 or 140-3 | Both versions accepted; agencies adopt existing 140-2 modules. | +| HIPAA | 140-2 or 140-3 | FIPS ensures encryption for ePHI; either version is valid. | +| HITECH | 140-2 or 140-3 | FIPS use aligns with encryption best practices for ePHI. | +| PCI DSS | 140-2 or 140-3 | Both versions recommended but not mandatory. | +| FedRAMP | 140-2 or 140-3 | FIPS required for encryption; both versions accepted. | +| TSA | 140-2 or 140-3 | Best practice for cryptographic protection; both versions accepted. | +| DFARS | 140-2 or 140-3 | Cryptographic modules for CUI must be FIPS compliant. | +| CMMC | 140-2 or 140-3 | FIPS required for Levels 2 and 3 compliance. | +| DoDIN APL | 140-2 or 140-3 | Approved IT products must include FIPS validation. | +| Common Criteria | 140-2 or 140-3 | Evaluations reference both FIPS versions for cryptographic security. | +| NSA CSfC | FIPS 140-2 or 140-3, transitioning to 140-3 | NSA accepts 140-2 but prefers newer certifications under 140-3. | +| CJIS | 140-2 or 140-3 | FIPS required for systems protecting criminal justice data. | +| State and Local Gov Programs | 140-2 or 140-3 | FIPS required for federal grant-funded security systems. | +| Intelligence Community | 140-2 transitioning to FIPS 140-3 | Current systems mostly use 140-2; newer systems adopt 140-3. | +| Military & Tactical Systems | 140-2 transitioning to FIPS 140-3 | 140-2 used widely; transitioning to 140-3 certifications for future tools. | +| Critical Infrastructure | 140-2 or 140-3 | Utilities and systems accept both versions depending on deployments. | +| FAA | FIPS 140-2 transitioning to FIPS 140-3** | 140-2 modules common in existing systems; new systems use 140-3. | +| Department of Veterans Affairs | 140-2 or 140-3 | Both versions used for securing sensitive health and personal data. | +| FERPA | 140-2 or 140-3 | Federal-funded educational systems align with 140-2 or 140-3. | +| Nuclear Regulatory Commission | 140-2 or 140-3 | Cryptography for nuclear systems relies on both versions. | +{{< /bootstrap-table >}} -- **Cryptographic module**: The OpenSSL software, comprised of libraries of FIPS‑validated algorithms that can be used by other applications. +Although FIPS 140 is primarily a North American government certification, it is widely recognized as a global cryptographic baseline. Several countries outside North America align their cryptographic requirements with FIPS, particularly in regulated industries such as finance, defense, and national infrastructure. -- **Cryptographic boundary**: The operational functions that use FIPS‑validated algorithms. For NGINX Plus, the cryptographic boundary includes all functionality that is implemented by the [`http_ssl`](http://nginx.org/en/docs/http/ngx_http_ssl_module.html), [`http_v2`](http://nginx.org/en/docs/http/ngx_http_v2_module.html), [`stream_ssl`](http://nginx.org/en/docs/stream/ngx_stream_ssl_module.html), [`mail_ssl`](http://nginx.org/en/docs/mail/ngx_mail_ssl_module.html), and [`http_auth_jwt`](http://nginx.org/en/docs/http/ngx_http_auth_jwt_module.html) modules. These modules implement SSL and TLS operations for inbound and outbound connections which use HTTP, HTTP/2, TCP, and mail protocols. +### Countries That Base Their Requirements on FIPS -- **NGINX Plus**: The NGINX Plus software application developed by NGINX, Inc. and delivered in binary format from NGINX servers. +{{}} +| Country/Region | FIPS Use | +|----------------------|-----------------------------------------------------------------------------| +| United States | Mandatory for federal systems and contractors; core to DoD and government. | +| Canada | Required under CMVP for federal cryptography and sensitive systems. | +| Germany | Defense, critical infrastructure, and NATO-related cryptography. | +| France | Defense and critical systems integrate FIPS for secure interoperability. | +| Netherlands | Financial, healthcare, and NATO-critical encryption systems reference FIPS. | +| Sweden | Applied in defense and NATO-aligned secure communications systems. | +| Denmark | Used in finance, healthcare, and NATO-related cryptographic activities. | +| Finland | Defense and critical infrastructure support FIPS for NATO collaboration. | +| Italy | Defense and finance systems integrate FIPS-certified cryptographic tools. | +| Spain | Used in NATO-linked systems and national critical infrastructure. | +| Poland | Government and NATO-secure communication systems rely on FIPS modules. | +| Estonia | E-governance and critical systems adopt FIPS for secure collaboration. | +| United Kingdom | NCSC references FIPS for defense, health, and procurement standards. | +| Australia | Applied in government, defense, and ASD-certified cryptographic modules. | +| New Zealand | Referenced in government and national-level cryptographic operations. | +| Israel | Trusted in defense, government, and financial cryptographic systems. | +| Japan | Recognized in secure government and financial cryptography applications. | +| UAE | Adopted for finance, energy, and interoperability with U.S. cryptography. | +{{< /bootstrap-table >}} -- **FIPS mode**: When the operating system is configured to run in FIPS mode, the OpenSSL cryptographic module operates in a mode that has been validated to be in compliance with FIPS 140-2 Level 2. Most operating systems do not run in FIPS mode by default, so explicit configuration is necessary to enable FIPS mode. -- **FIPS validated**: A component of the OpenSSL cryptographic module (the OpenSSL FIPS Object Module) is formally validated by an authorized certification laboratory. The validation holds if the module is built from source with no modifications to the source or build process. The implementation of FIPS mode that is present in operating system vendors’ distributions of OpenSSL contains this validated module. +## FIPS Compliant or FIPS Validated -- **FIPS compliant**: NGINX Plus is compliant with FIPS 140-2 Level 1 within the cryptographic boundary when used with a FIPS‑validated OpenSSL cryptographic module on an operating system running in FIPS mode. +FIPS validation is a multistep process that certifies cryptographic modules through formal testing under the [Cryptographic Module Validation Program](https://csrc.nist.gov/Projects/cryptographic-module-validation-program/cmvp-flow) (CMVP). The process is managed by the NIST and requires accredited third-party laboratories to evaluate the cryptographic module. Once a module passes validation, it is officially recognized as FIPS-certified. + +In contrast, a system that is FIPS compliant adheres to the security requirements outlined in the FIPS standard by using cryptographic algorithms or modules that implement FIPS-approved functions, such as AES for encryption or SHA-256 for hashing. However, compliance alone does not indicate formal validation or certification under the CMVP program. + + +## FIPS compliance with NGINX Plus + +NGINX Plus is **FIPS 140-2 Level 1** and **FIPS 140-3 Level 1 compliant**. + +NGINX Plus uses the OpenSSL cryptographic module exclusively for all operations relating to the decryption and encryption of SSL/TLS, HTTP/2 and HTTP/3 traffic. + +When NGINX Plus is executed on an operating system where a FIPS‑validated OpenSSL cryptographic module is present and FIPS mode is enabled, NGINX Plus is compliant with FIPS 140-2 Level 1/ FIPS 140-3 Level 1 with respect to the decryption and encryption of SSL/TLS, HTTP/2 or HTTP/3 traffic. + +## FIPS compliance with NGINX Open Source + +While NGINX Plus is tested to work on FIPS-enabled operating systems in FIPS mode, NGINX Open Source is not verified for such environments, especially when third-party builds or modules implementing custom cryptographic functions are used. Misconfigurations, such as enabling TLS 1.0 or using deprecated ciphers (e.g., 3DES), can invalidate FIPS compliance. + +Compiling NGINX Open Source for FIPS mode may also require additional OS-level dependencies beyond its core requirements, potentially introducing unintended risks. Organizations should consult their security and compliance teams to ensure their configurations meet FIPS requirements. + +## FIPS validation of operating systems + +Several operating system vendors have obtained FIPS 140-2 Level 1 and 140-3 Level 1 validation for the OpenSSL Cryptographic Module included with their respective operating systems: + +- RedHat: [RedHat FIPS Certifications](https://access.redhat.com/compliance/fips) +- Ubuntu: [Overview of FIPS-certified modules](https://documentation.ubuntu.com/security/docs/compliance/fips/fips-overview/) +- Oracle: [Oracle FIPS Certifications](https://www.oracle.com/corporate/security-practices/assurance/development/external-security-evaluations/fips/certifications/) +- SUSE: [SUSE FIPS 140-3 cryptographic certificates](https://www.suse.com/c/suse-has-received-first-fips-140-3-cryptographic-certificates/) +- AWS: [FIPS 140-3 Compliance](https://aws.amazon.com/compliance/fips/) +- Amazon Linux: [Achieving FIPS 140-3 validation](https://aws.amazon.com/blogs/compute/amazon-linux-2023-achieves-fips-140-3-validation/) + +You also can verify whether your operating system or cryptographic module is FIPS-validated using the [NIST database search tool](https://csrc.nist.gov/Projects/cryptographic-module-validation-program/validated-modules/search). ## Verification of Correct Operation of NGINX Plus The following process describes how to deploy NGINX Plus in a FIPS‑compliant fashion and then verify that the FIPS operations are correctly performed. -The process uses Red Hat Enterprise Linux (RHEL) version 7.4 as an example, and can be adapted for other Linux operating systems that can be configured in FIPS mode. +The process uses Red Hat Enterprise Linux (RHEL) release 9.6 as an example, and can be adapted for other Linux operating systems that can be configured in FIPS mode. ### Step 1: Configure the Operating System to Use FIPS Mode -For the purposes of the following demonstration, we installed and configured a RHEL 7.4 server. The [Red Hat FIPS documentation](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/chap-federal_standards_and_regulations#sec-Enabling-FIPS-Mode) explains how to switch the operating system between FIPS mode and non‑FIPS mode by editing the boot options and restarting the system. +For the purposes of the following demonstration, we installed and configured a RHEL 9.6 server. The [Red Hat FIPS documentation](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/chap-federal_standards_and_regulations#sec-Enabling-FIPS-Mode) explains how to switch the operating system between FIPS mode and non‑FIPS mode by editing the boot options and restarting the system. + +For instructions for enabling FIPS mode on other FIPS‑compliant Linux operating systems, see the operating system documentation, for example: -For instructions for enabling FIPS mode on other FIPS‑compliant Linux operating systems, see the operating system documentation (for example, [Oracle Linux](https://docs.oracle.com/cd/E52668_01/E54670/html/ol7-fips-enable.html), [Ubuntu](https://ubuntu.com/security/certifications/docs/fips-faq)). +- RHEL 9: [Switching to FIPS mode](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/switching-rhel-to-fips-mode_security-hardening) -### Step 2: Verify the Operating System and OpenSSL Are in FIPS Mode +- Ubuntu: [Switching to FIPS mode](https://documentation.ubuntu.com/security/docs/compliance/fips/how-to-install-ubuntu-with-fips/) + +- SLES: [How to enable FIPS](https://www.suse.com/support/kb/doc/?id=000019432) + +- Oracle Linux 9: [Configuring FIPS mode](https://docs.oracle.com/en/operating-systems/oracle-linux/9/security/configuring_fips_mode.html#configuring-fips-mode) + +- Amazon Linux 2023: [Enabling FIPS mode](https://docs.aws.amazon.com/linux/al2023/ug/fips-mode.html) + +- Amazon Linux 2: [Enabling FIPS mode](https://docs.aws.amazon.com/linux/al2/ug/fips-mode.html) + +- AlmaLinux: [FIPS Validation for AlmaLinux](https://almalinux.org/blog/2023-09-19-fips-validation-for-almalinux/) + + +### Step 2: Verify the Operating System is in FIPS Mode You can verify that the operating system is in FIPS mode and that the version of OpenSSL provided by the operating system vendor is FIPS‑compliant by using the following tests. -**Check operating system flags**: When the operating system is in FIPS mode, ```crypto.fips_enabled``` is ```1```; otherwise, it is ```0```: +**Check operating system flags**: When the operating system is in FIPS mode, `crypto.fips_enabled` kernlel flag is `1`; otherwise, it is `0`: ```shell -sudo sysctl –a | grep fips +sudo sysctl -a | grep fips +``` + +The output of the command shows that FIPS is enabled at the kernel level: +```none crypto.fips_enabled = 1 +crypto.fips_name = Red Hat Enterprise Linux 9 - Kernel Cryptographic API +crypto.fips_version = 5.14.0-570.39.1.el9_6.aarch64 +``` + +Check kernel logs for FIPS algorithm registration: +```shell +journalctl -k -o cat -g alg: +``` + +The output of the command verifies the status of algorithm self-tests and whether certain algorithms are registered, passed FIPS self-tests, or are disabled due to FIPS mode being active: + +```none +alg: self-tests for pkcs1pad(rsa-generic,sha512) (pkcs1pad(rsa,sha512)) passed +alg: self-tests for pkcs1pad(rsa-generic,sha256) (pkcs1pad(rsa,sha256)) passed +alg: self-tests for cbc-aes-ce (cbc(aes)) passed +alg: self-tests for jitterentropy_rng (jitterentropy_rng) passed +alg: poly1305 (poly1305-neon) is disabled due to FIPS +alg: xchacha12 (xchacha12-neon) is disabled due to FIPS +alg: xchacha20 (xchacha20-neon) is disabled due to FIPS +``` + +Beyond kernel-level verification, you can ensure that the whole operating system environment is configured for FIPS compliance: +```shell +sudo fips-mode-setup --check +``` +The output of the command shows that FIPS is running: +```none +FIPS mode is enabled. +``` + +### Step 3: Verify the OpenSSL is in FIPS Mode + +**Determine the OpenSSL FIPS Provider is active**: This test verifies the correct version of OpenSSL and that the OpenSSL FIPS Provider is active: + +```shell +openssl list -providers | grep -A3 fips +``` +The output of the command shows the FIPS provider status: +```none + fips + name: Red Hat Enterprise Linux 9 - OpenSSL FIPS Provider + version: 3.0.7-395c1a240fbfffd8 + status: active ``` -**Determine whether OpenSSL can perform SHA1 hashes**: This test verifies the correct operation of OpenSSL. The SHA1 hash algorithm is permitted in all modes, so failure of this command indicates that the OpenSSL implementation does not work properly: +**Determine whether OpenSSL can perform SHA1 hashes**: This test verifies the correct operation of OpenSSL. The SHA-1 hash algorithm, while considered weak, is still permitted in FIPS mode as it is included in FIPS-approved standards for certain legacy use cases. Failure of this command indicates that the OpenSSL implementation is not working properly: ```shell openssl sha1 /dev/null +``` +The result of the command, showing the SHA1 checksum of `/dev/null`: + +```none SHA1(/dev/null)= da39a3ee5e6b4b0d3255bfef95601890afd80709 ``` -**Determine whether OpenSSL can perform MD5 hashes**: This test verifies that OpenSSL is running in FIPS mode. MD5 is not a permitted hash algorithm in FIPS mode, so an attempt to use it fails: +**Determine whether OpenSSL allows MD5 hashes**: This test verifies that OpenSSL is running in FIPS mode. MD5 is not a permitted hash algorithm in FIPS mode, so an attempt to use it fails: ```shell openssl md5 /dev/null -Error setting digest md5 -140647163811744:error:060800A3:digital envelope routines:EVP_DigestInit _ex:disabled for fips:digest.c:251: +``` +The result of the command: + +```none +Error setting digest +200458BAFFFF0000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:355:Global default library context, Algorithm (MD5 : 95), Properties () +200458BAFFFF0000:error:03000086:digital envelope routines:evp_md_init_internal:initialization error:crypto/evp/digest.c:272: ``` If OpenSSL is not running in FIPS mode, the MD5 hash functions normally: ```shell openssl md5 /dev/null +``` +The result of the command, showing the MD5 checksum of `/dev/null`: + +```none MD5(/dev/null)= d41d8cd98f00b204e9800998ecf8427e ``` ### Step 3: Install NGINX Plus on the Operating System -Follow the [F5 NGINX documentation](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-plus/) to install NGINX Plus on the host operating system, either directly from the [NGINX Plus repository](https://account.f5.com/myf5), or by downloading the **nginx-plus** package (**rpm** or **deb** package) onto another system and manually installing it on the host operating system. +Follow the [F5 NGINX Plus Installation guide](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-plus/) to install NGINX Plus on the host operating system, either directly from the [NGINX Plus repository](https://account.f5.com/myf5), or by downloading the **nginx-plus** package (**rpm** or **deb** package) onto another system and manually installing it on the host operating system. **Verify that NGINX Plus is correctly installed**: Run the following command to confirm that NGINX Plus is installed and is using the expected OpenSSL cryptographic module: ```shell nginx -V -nginx version: nginx/1.15.2 (nginx-plus-r16) -built by gcc 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC) -built with OpenSSL 1.0.2k-fips 26 Jan 2017 ``` +Sample output from the command: -Observe that the version number of the OpenSSL library includes the `–fips` suffix. This indicates that the library is FIPS‑validated, but does not confirm that it is running in FIPS mode. +```shell +nginx version: nginx/1.29.0 (nginx-plus-r35) +built by gcc 11.5.0 20240719 (Red Hat 11.5.0-5) (GCC) +built with OpenSSL 3.2.2 4 Jun 2024 +``` +Note that OpenSSL 1.0.x might include the `–fips` suffix to indicate that the library was linked with a FIPS-validated module, but it did not confirm that the library was operating in FIPS mode. Starting with OpenSSL 3.0, the concept of Providers was introduced, allowing explicit verification of FIPS validation by listing providers with the `openssl list -providers | grep fips` command. **Configure NGINX Plus to serve a simple SSL/TLS‑protected website**: Add the following simple configuration to NGINX Plus: @@ -110,8 +258,6 @@ server { ssl_certificate /etc/nginx/ssl/test.crt; ssl_certificate_key /etc/nginx/ssl/test.key; - ssl_protocols TLSv1.2 TLSv1.3; - location / { root /usr/share/nginx/html; index index.html index.htm; @@ -122,7 +268,7 @@ server { If necessary, you can generate a self‑signed certificate for test purposes: ```shell -mkdir -p /etc/nginx/ssl +mkdir -p /etc/nginx/ssl && \ openssl req -newkey rsa:2048 -nodes -keyout /etc/nginx/ssl/test.key -x509 -days 365 -out /etc/nginx/ssl/test.crt ``` @@ -134,7 +280,7 @@ Verify that you can access the website using HTTPS from a remote host. Connect t Use `openssl s_client` for this test because it unambiguously confirms which SSL/TLS cipher was negotiated in the connection. After some debugging information (including the cipher selected), the body of the default “Welcome to nginx!” greeting page is displayed. -### Step 4: Verify Compliance with FIPS 140-2 +### Step 4: Verify Compliance with FIPS FIPS 140-2 disallows the use of some cryptographic algorithms, including the Camellia block cipher. We can test compliance with FIPS 140-2 by issuing SSL/TLS requests with known ciphers on another (non-FIPS-mode) server: @@ -164,6 +310,8 @@ Note that if you attempt to issue the client request on a host running in FIPS m This cipher is considered secure by NGINX Plus and is permitted by FIPS 140-2. The SSL handshake succeeds. + + ## Which Ciphers Are Disabled in FIPS Mode? The FIPS 140-2 standard only permits a [subset of the typical SSL and TLS ciphers](https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402annexa.pdf). @@ -187,10 +335,53 @@ When you configure NGINX Plus with the `ssl_ciphers ALL` directive, NGINX Plus p - `TLS_RSA_WITH_RC4_128_SHA` - `TLS_RSA_WITH_SEED_CBC_SHA` + +In addition, FIPS 140-3 disallows the use of several ciphers and algorithms that were once allowed or still allowed under FIPS 140-2. + +#### 3DES +The `3DES` or Triple DES cipher was once supported but is no longer permitted by NIST as of January 1, 2024. + +#### SHA-1 +The `SHA-1` algorithm is not permitted for cryptographic use under FIPS 140-3. + +#### RC4 +The `RC4` bulk encryption cipher suite is not allowed in FIPS 140-3. + +#### Weak Cipher Suites +In TLS (Transport Layer Security) deployments, weak cipher suites such as `3DES`, `DES`, `RC4`, `ANON`, and `NULL` are not permitted under FIPS 140-3. + + +## Definition of Terms + +This statement uses the following terms: + +- **Cryptographic module**: The OpenSSL software, comprised of libraries of FIPS‑validated algorithms that can be used by other applications. + +- **Cryptographic boundary**: The operational functions that use FIPS‑validated algorithms. For NGINX Plus, the cryptographic boundary includes all functionality that is implemented by the [`http_ssl`](https://nginx.org/en/docs/http/ngx_http_ssl_module.html), [`http_v2`](https://nginx.org/en/docs/http/ngx_http_v2_module.html), [`http_v3`](https://nginx.org/en/docs/http/ngx_http_v3_module.html), [`stream_ssl`](https://nginx.org/en/docs/stream/ngx_stream_ssl_module.html), [`mail_ssl`](https://nginx.org/en/docs/mail/ngx_mail_ssl_module.html), and [`http_auth_jwt`](https://nginx.org/en/docs/http/ngx_http_auth_jwt_module.html) modules. These modules implement SSL and TLS operations for inbound and outbound connections which use HTTP, HTTP/2, HTTP/3, TCP, and mail protocols. + +- **NGINX Plus**: The NGINX Plus software application developed by NGINX, Inc. and delivered in binary format from NGINX servers. + +- **FIPS mode**: When the operating system is configured to run in FIPS mode, the OpenSSL cryptographic module operates in a mode that has been validated to be in compliance with FIPS 140-2 Level 2. Most operating systems do not run in FIPS mode by default, so explicit configuration is necessary to enable FIPS mode. + +- **FIPS validated**: A component of the OpenSSL cryptographic module (the OpenSSL FIPS Object Module) is formally validated by an authorized certification laboratory. The validation holds if the module is built from source with no modifications to the source or build process. The implementation of FIPS mode that is present in operating system vendors’ distributions of OpenSSL contains this validated module. + +- **FIPS compliant**: NGINX Plus is compliant with FIPS 140-2 Level 1 within the cryptographic boundary when used with a FIPS‑validated OpenSSL cryptographic module on an operating system running in FIPS mode. + + ## Conclusion -NGINX Plus can be used to decrypt and encrypt SSL/TLS‑encrypted network traffic in deployments that require FIPS 140-2 Level 1 compliance. +NGINX Plus can be used to decrypt and encrypt SSL/TLS‑encrypted network traffic in deployments that require FIPS 140-2 Level 1 or FIPS 140-3 Level 1 compliance. + +The process described above may be used to verify that NGINX Plus is operating in conformance with the FIPS 140-2 Level 1 and FIPS 140-3 Level 1 standards. + + +## See also: + +[FIPS 140-3 Standard in the PDF format](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf) + +[FIPS compliance with NGINX Plus and Red Hat Enterprise Linux](https://www.f5.com/pdf/technology-alliances/fips-compliance-made-simple-with-f5-and-red-hat-one-pager.pdf) + +[F5 NGINX Plus running on Red Hat Enterprise Linux is now FIPS 140-3 compliant](https://www.redhat.com/en/blog/f5-nginx-plus-running-red-hat-enterprise-linux-now-fips-140-3-compliant) -The process described above may be used to verify that NGINX Plus is operating in conformance with the FIPS 140-2 Level 1 standard. From b81db27da180fd21c7b7dc06c93d74476f4f9562 Mon Sep 17 00:00:00 2001 From: Yaroslav Zhuravlev Date: Tue, 9 Sep 2025 21:01:00 +0100 Subject: [PATCH 3/6] Feedback, FIPS-3 SSL tests --- content/nginx/fips-compliance-nginx-plus.md | 102 +++++++++++++------- 1 file changed, 69 insertions(+), 33 deletions(-) diff --git a/content/nginx/fips-compliance-nginx-plus.md b/content/nginx/fips-compliance-nginx-plus.md index 54a7a16d1..94d66497a 100644 --- a/content/nginx/fips-compliance-nginx-plus.md +++ b/content/nginx/fips-compliance-nginx-plus.md @@ -37,13 +37,13 @@ Many federal programs and regulations mandate FIPS 140 validation, which serves | CMMC | 140-2 or 140-3 | FIPS required for Levels 2 and 3 compliance. | | DoDIN APL | 140-2 or 140-3 | Approved IT products must include FIPS validation. | | Common Criteria | 140-2 or 140-3 | Evaluations reference both FIPS versions for cryptographic security. | -| NSA CSfC | FIPS 140-2 or 140-3, transitioning to 140-3 | NSA accepts 140-2 but prefers newer certifications under 140-3. | +| NSA CSfC | 140-2 transitioning to 140-3 | NSA accepts 140-2 but prefers newer certifications under 140-3. | | CJIS | 140-2 or 140-3 | FIPS required for systems protecting criminal justice data. | | State and Local Gov Programs | 140-2 or 140-3 | FIPS required for federal grant-funded security systems. | | Intelligence Community | 140-2 transitioning to FIPS 140-3 | Current systems mostly use 140-2; newer systems adopt 140-3. | | Military & Tactical Systems | 140-2 transitioning to FIPS 140-3 | 140-2 used widely; transitioning to 140-3 certifications for future tools. | | Critical Infrastructure | 140-2 or 140-3 | Utilities and systems accept both versions depending on deployments. | -| FAA | FIPS 140-2 transitioning to FIPS 140-3** | 140-2 modules common in existing systems; new systems use 140-3. | +| FAA | 140-2 transitioning to FIPS 140-3 | 140-2 modules common in existing systems; new systems use 140-3. | | Department of Veterans Affairs | 140-2 or 140-3 | Both versions used for securing sensitive health and personal data. | | FERPA | 140-2 or 140-3 | Federal-funded educational systems align with 140-2 or 140-3. | | Nuclear Regulatory Commission | 140-2 or 140-3 | Cryptography for nuclear systems relies on both versions. | @@ -54,28 +54,40 @@ Although FIPS 140 is primarily a North American government certification, it is ### Countries That Base Their Requirements on FIPS {{}} -| Country/Region | FIPS Use | -|----------------------|-----------------------------------------------------------------------------| -| United States | Mandatory for federal systems and contractors; core to DoD and government. | -| Canada | Required under CMVP for federal cryptography and sensitive systems. | -| Germany | Defense, critical infrastructure, and NATO-related cryptography. | -| France | Defense and critical systems integrate FIPS for secure interoperability. | -| Netherlands | Financial, healthcare, and NATO-critical encryption systems reference FIPS. | -| Sweden | Applied in defense and NATO-aligned secure communications systems. | -| Denmark | Used in finance, healthcare, and NATO-related cryptographic activities. | -| Finland | Defense and critical infrastructure support FIPS for NATO collaboration. | -| Italy | Defense and finance systems integrate FIPS-certified cryptographic tools. | -| Spain | Used in NATO-linked systems and national critical infrastructure. | -| Poland | Government and NATO-secure communication systems rely on FIPS modules. | -| Estonia | E-governance and critical systems adopt FIPS for secure collaboration. | -| United Kingdom | NCSC references FIPS for defense, health, and procurement standards. | -| Australia | Applied in government, defense, and ASD-certified cryptographic modules. | -| New Zealand | Referenced in government and national-level cryptographic operations. | -| Israel | Trusted in defense, government, and financial cryptographic systems. | -| Japan | Recognized in secure government and financial cryptography applications. | -| UAE | Adopted for finance, energy, and interoperability with U.S. cryptography. | +| Country/Region | FIPS Use | +|----------------------|-----------------------------------------------| +| Australia | Referenced for government, defense, and cryptography systems. | +| Canada | Mandatory for federal and sensitive systems. | +| Denmark | Referenced in finance, healthcare, and NATO-related systems. | +| Estonia | Adopted for e-governance and critical systems. | +| Finland | Relied on for defense and NATO collaboration. | +| France | Relied on for defense and secure systems. | +| Germany | Relied on for defense, critical infrastructure, and NATO interoperability. | +| Israel | Trusted in defense, government, and financial systems. | +| Italy | Relied on for defense and financial cryptography. | +| Japan | Referenced in government and financial cryptographic practices. | +| Netherlands | Referenced in finance, healthcare, and NATO cryptography systems. | +| New Zealand | Referenced for government and national cryptography. | +| Poland | Relied on for secure government and NATO-linked communications. | +| Spain | Referenced in NATO interoperability and critical systems. | +| Sweden | Relied on for defense and secure NATO communications. | +| UAE | Trusted in finance, energy, and interoperability with the U.S. cryptography. | +| United Kingdom | Referenced for defense, health, and procurement standards. | +| United States | Mandatory for federal government systems and contractors. | {{< /bootstrap-table >}} +where: + +- Mandatory: used for countries that officially require FIPS compliance (United States, Canada). + +- Relied on: used for countries where FIPS plays a critical role in defense, finance, and secure communication. While not officially mandated, these countries depend on FIPS due to interoperability with NATO systems. + +- Referenced: used when industries or governments incorporate FIPS-certified cryptography as part of their standards but do not enforce it as mandatory. + +- Adopted: used when governments or systems actively use FIPS frameworks for secure collaboration. + +- Trusted: Used in contexts where FIPS is recognized as a reliable standard for industries such as finance and energy. + ## FIPS Compliant or FIPS Validated @@ -113,11 +125,17 @@ You also can verify whether your operating system or cryptographic module is FIP ## Verification of Correct Operation of NGINX Plus -The following process describes how to deploy NGINX Plus in a FIPS‑compliant fashion and then verify that the FIPS operations are correctly performed. +The following process describes how to deploy NGINX Plus in a FIPS‑compliant fashion and then verify that the FIPS operations are correctly performed: + +- [Verify](#os-fips-check) if the operating system is running in FIPS mode. If not, [configure](#os-fips-setup) it to enable FIPS mode. + +- [Ensure](#openssl-fips-check) that the OpenSSL library is operating in FIPS mode. + +- Run simple checks for [OpenSSL](#openssl-fips-check) and [NGINX Plus](#nginx-plus-fips-check) to ensure FIPS mode. The process uses Red Hat Enterprise Linux (RHEL) release 9.6 as an example, and can be adapted for other Linux operating systems that can be configured in FIPS mode. -### Step 1: Configure the Operating System to Use FIPS Mode +### Step 1: Configure the Operating System to Use FIPS Mode {#os-fips-setup} For the purposes of the following demonstration, we installed and configured a RHEL 9.6 server. The [Red Hat FIPS documentation](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/chap-federal_standards_and_regulations#sec-Enabling-FIPS-Mode) explains how to switch the operating system between FIPS mode and non‑FIPS mode by editing the boot options and restarting the system. @@ -131,14 +149,14 @@ For instructions for enabling FIPS mode on other FIPS‑compliant Linux operatin - Oracle Linux 9: [Configuring FIPS mode](https://docs.oracle.com/en/operating-systems/oracle-linux/9/security/configuring_fips_mode.html#configuring-fips-mode) -- Amazon Linux 2023: [Enabling FIPS mode](https://docs.aws.amazon.com/linux/al2023/ug/fips-mode.html) +- Amazon Linux 2023: [Enabling FIPS mode](https://docs.aws.amazon.com/linux/al2023/ug/fips-mode.html) - Amazon Linux 2: [Enabling FIPS mode](https://docs.aws.amazon.com/linux/al2/ug/fips-mode.html) - AlmaLinux: [FIPS Validation for AlmaLinux](https://almalinux.org/blog/2023-09-19-fips-validation-for-almalinux/) -### Step 2: Verify the Operating System is in FIPS Mode +### Step 2: Verify the Operating System is in FIPS Mode {#os-fips-check} You can verify that the operating system is in FIPS mode and that the version of OpenSSL provided by the operating system vendor is FIPS‑compliant by using the following tests. @@ -181,7 +199,7 @@ The output of the command shows that FIPS is running: FIPS mode is enabled. ``` -### Step 3: Verify the OpenSSL is in FIPS Mode +### Step 3: Verify the OpenSSL is in FIPS Mode {#openssl-fips-check} **Determine the OpenSSL FIPS Provider is active**: This test verifies the correct version of OpenSSL and that the OpenSSL FIPS Provider is active: @@ -231,7 +249,7 @@ The result of the command, showing the MD5 checksum of `/dev/null`: MD5(/dev/null)= d41d8cd98f00b204e9800998ecf8427e ``` -### Step 3: Install NGINX Plus on the Operating System +### Step 3: Install NGINX Plus on the Operating System {#nginx-plus-instll} Follow the [F5 NGINX Plus Installation guide](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-plus/) to install NGINX Plus on the host operating system, either directly from the [NGINX Plus repository](https://account.f5.com/myf5), or by downloading the **nginx-plus** package (**rpm** or **deb** package) onto another system and manually installing it on the host operating system. @@ -280,9 +298,9 @@ Verify that you can access the website using HTTPS from a remote host. Connect t Use `openssl s_client` for this test because it unambiguously confirms which SSL/TLS cipher was negotiated in the connection. After some debugging information (including the cipher selected), the body of the default “Welcome to nginx!” greeting page is displayed. -### Step 4: Verify Compliance with FIPS +### Step 4: Verify Compliance with FIPS 140-2 {#fips-2-check} -FIPS 140-2 disallows the use of some cryptographic algorithms, including the Camellia block cipher. We can test compliance with FIPS 140-2 by issuing SSL/TLS requests with known ciphers on another (non-FIPS-mode) server: +FIPS 140-2 disallows the use of some cryptographic algorithms, including the Camellia block cipher. You can test compliance with FIPS 140-2 by issuing SSL/TLS requests with known ciphers on another (non-FIPS-mode) server: #### RC4-MD5 @@ -302,15 +320,33 @@ This cipher is considered secure but is not permitted by the FIPS standard. The Note that if you attempt to issue the client request on a host running in FIPS mode, it fails because the OpenSSL client cannot use this cipher. + +### Step 5: Verify Compliance with FIPS 140-3 {#fips-3-check} + +In addition, FIPS 140-3 disallows the use of several ciphers and algorithms that were once allowed or still allowed under FIPS 140-2: + #### AES256-SHA +Althoguh this cipher is permitted by FIPS 140-2, it is not permitted by FIPS 140-3. The SSL handshake fails in case of FIPS 140-3 and succeeds in case of FIPS 140-2. + ```shell (echo "GET /" ; sleep 1) | openssl s_client -connect :443 -cipher AES256-SHA ``` -This cipher is considered secure by NGINX Plus and is permitted by FIPS 140-2. The SSL handshake succeeds. +#### 3DES + +The `3DES` or Triple DES cipher was once supported but is no longer permitted by NIST as of January 1, 2024. The SSL handshake always fails. + +```shell +(echo "GET /" ; sleep 1) | openssl s_client -connect :443 -cipher 3DES +``` +#### RC4 +The `RC4` bulk encryption cipher suite is not allowed in FIPS 140-3. The SSL handshake always fails. +```shell +(echo "GET /" ; sleep 1) | openssl s_client -connect :443 -cipher RC4 +``` ## Which Ciphers Are Disabled in FIPS Mode? @@ -357,7 +393,7 @@ This statement uses the following terms: - **Cryptographic module**: The OpenSSL software, comprised of libraries of FIPS‑validated algorithms that can be used by other applications. -- **Cryptographic boundary**: The operational functions that use FIPS‑validated algorithms. For NGINX Plus, the cryptographic boundary includes all functionality that is implemented by the [`http_ssl`](https://nginx.org/en/docs/http/ngx_http_ssl_module.html), [`http_v2`](https://nginx.org/en/docs/http/ngx_http_v2_module.html), [`http_v3`](https://nginx.org/en/docs/http/ngx_http_v3_module.html), [`stream_ssl`](https://nginx.org/en/docs/stream/ngx_stream_ssl_module.html), [`mail_ssl`](https://nginx.org/en/docs/mail/ngx_mail_ssl_module.html), and [`http_auth_jwt`](https://nginx.org/en/docs/http/ngx_http_auth_jwt_module.html) modules. These modules implement SSL and TLS operations for inbound and outbound connections which use HTTP, HTTP/2, HTTP/3, TCP, and mail protocols. +- **Cryptographic boundary**: The operational functions that use FIPS‑validated algorithms. For NGINX Plus, the cryptographic boundary includes all functionality that is implemented by the [`http_auth_jwt`](https://nginx.org/en/docs/http/ngx_http_auth_jwt_module.html), [`http_ssl`](https://nginx.org/en/docs/http/ngx_http_ssl_module.html), [`http_v2`](https://nginx.org/en/docs/http/ngx_http_v2_module.html), [`http_v3`](https://nginx.org/en/docs/http/ngx_http_v3_module.html), [`mail_ssl`](https://nginx.org/en/docs/mail/ngx_mail_ssl_module.html), and [`stream_ssl`](https://nginx.org/en/docs/stream/ngx_stream_ssl_module.html) modules. These modules implement SSL and TLS operations for inbound and outbound connections which use HTTP, HTTP/2, HTTP/3, TCP, and mail protocols. - **NGINX Plus**: The NGINX Plus software application developed by NGINX, Inc. and delivered in binary format from NGINX servers. @@ -365,7 +401,7 @@ This statement uses the following terms: - **FIPS validated**: A component of the OpenSSL cryptographic module (the OpenSSL FIPS Object Module) is formally validated by an authorized certification laboratory. The validation holds if the module is built from source with no modifications to the source or build process. The implementation of FIPS mode that is present in operating system vendors’ distributions of OpenSSL contains this validated module. -- **FIPS compliant**: NGINX Plus is compliant with FIPS 140-2 Level 1 within the cryptographic boundary when used with a FIPS‑validated OpenSSL cryptographic module on an operating system running in FIPS mode. +- **FIPS compliant**: NGINX Plus is compliant with FIPS 140-2 Level 1 and FIPS 140-3 Level 1 within the cryptographic boundary when used with a FIPS‑validated OpenSSL cryptographic module on an operating system running in FIPS mode. ## Conclusion From b12fe2029dc04d921a4fbb7f07b7666cee19eee2 Mon Sep 17 00:00:00 2001 From: Yaroslav Zhuravlev Date: Wed, 10 Sep 2025 15:49:09 +0100 Subject: [PATCH 4/6] self-review, fips2 vs fips3 tests --- content/nginx/fips-compliance-nginx-plus.md | 207 +++++++++++--------- 1 file changed, 115 insertions(+), 92 deletions(-) diff --git a/content/nginx/fips-compliance-nginx-plus.md b/content/nginx/fips-compliance-nginx-plus.md index 94d66497a..32c280c50 100644 --- a/content/nginx/fips-compliance-nginx-plus.md +++ b/content/nginx/fips-compliance-nginx-plus.md @@ -12,101 +12,102 @@ type: The Federal Information Processing Standard (FIPS), issued by the [U.S. National Institute of Standards and Technology](https://www.nist.gov/) (NIST), defines mandatory security requirements for cryptographic modules used in federal IT systems. [FIPS 140-2](https://csrc.nist.gov/pubs/fips/140-2/upd2/final), and its successor [FIPS 140-3](https://csrc.nist.gov/pubs/fips/140-3/final), establish strict standards to protect sensitive but unclassified information, including government communications and citizen data. +## Why FIPS-140 Matters -## Why FIPS Compliance Matters +FIPS 140 is a mandatory cryptographic standard in the United States and Canada for federal agencies, their contractors, and many regulated industries. -U.S. federal agencies and their contractors must use FIPS-validated cryptographic modules for systems supporting government operations. +Non-compliance can result to contract loss, restricted project access, fines, or, in severe cases, data breaches compromising personal information or national security. -Non-compliance can lead to contract loss, restricted project access, or fines. In recent years, enforcement of FIPS compliance has increased significantly across regulated industries. -At worst, it can lead to theft of personal information or national security documents. - -Many federal programs and regulations mandate FIPS 140 validation, which serves as a foundation for safeguarding sensitive data in various industries. +In addition, non regulated sectors handling sensitive data, such as finance, healthcare, energy, have widely adopted FIPS to strengthen data protection and operational security. ### FIPS Compliance Across U.S. Programs, Regulations, and Industries +Currently, both FIPS 140-2 and FIPS 140-3 certifications are accepted. However, FIPS 140-2 is being phased out as part of the [FIPS 140-3 transition plan](https://csrc.nist.gov/projects/fips-140-3-transition-effort). After September 22, 2026, only FIPS 140-3 certifications will be recognized. Organizations are encouraged to migrate to FIPS 140-3 to meet updated cryptographic security requirements. + {{}} -| **Program/Regulation/Industry** | **FIPS 140-2/140-3 Requirement** | **Current Status** | -|-----------------------------------|---------------------------------------------|------------------------------------------------------------------------------------------------------| -| FISMA | 140-2 or 140-3 | Both versions accepted; agencies adopt existing 140-2 modules. | -| HIPAA | 140-2 or 140-3 | FIPS ensures encryption for ePHI; either version is valid. | -| HITECH | 140-2 or 140-3 | FIPS use aligns with encryption best practices for ePHI. | -| PCI DSS | 140-2 or 140-3 | Both versions recommended but not mandatory. | -| FedRAMP | 140-2 or 140-3 | FIPS required for encryption; both versions accepted. | -| TSA | 140-2 or 140-3 | Best practice for cryptographic protection; both versions accepted. | -| DFARS | 140-2 or 140-3 | Cryptographic modules for CUI must be FIPS compliant. | -| CMMC | 140-2 or 140-3 | FIPS required for Levels 2 and 3 compliance. | -| DoDIN APL | 140-2 or 140-3 | Approved IT products must include FIPS validation. | -| Common Criteria | 140-2 or 140-3 | Evaluations reference both FIPS versions for cryptographic security. | -| NSA CSfC | 140-2 transitioning to 140-3 | NSA accepts 140-2 but prefers newer certifications under 140-3. | -| CJIS | 140-2 or 140-3 | FIPS required for systems protecting criminal justice data. | -| State and Local Gov Programs | 140-2 or 140-3 | FIPS required for federal grant-funded security systems. | -| Intelligence Community | 140-2 transitioning to FIPS 140-3 | Current systems mostly use 140-2; newer systems adopt 140-3. | -| Military & Tactical Systems | 140-2 transitioning to FIPS 140-3 | 140-2 used widely; transitioning to 140-3 certifications for future tools. | -| Critical Infrastructure | 140-2 or 140-3 | Utilities and systems accept both versions depending on deployments. | -| FAA | 140-2 transitioning to FIPS 140-3 | 140-2 modules common in existing systems; new systems use 140-3. | -| Department of Veterans Affairs | 140-2 or 140-3 | Both versions used for securing sensitive health and personal data. | -| FERPA | 140-2 or 140-3 | Federal-funded educational systems align with 140-2 or 140-3. | -| Nuclear Regulatory Commission | 140-2 or 140-3 | Cryptography for nuclear systems relies on both versions. | +| **Program/Regulation/Industry** | **FIPS 140-2/140-3 Requirement** | **Current Status** | +|---------------------------------|----------------------------------|---------------------------------------------------------------------| +| CJIS | 140-2 or 140-3 | FIPS required for systems protecting criminal justice data. | +| CMMC | 140-2 or 140-3 | FIPS required for Levels 2 and 3 compliance. | +| Common Criteria | 140-2 or 140-3 | Evaluations reference both FIPS versions for cryptographic security. | +| Critical Infrastructure | 140-2 or 140-3 | Utilities and systems accept both versions depending on deployments. | +| Department of Veterans Affairs| 140-2 or 140-3 | Both versions used for securing sensitive health and personal data. | +| DFARS | 140-2 or 140-3 | Cryptographic modules for CUI must be FIPS compliant. | +| DoDIN APL | 140-2 or 140-3 | Approved IT products must include FIPS validation. | +| FAA | 140-2 transitioning to 140-3 | 140-2 modules common in existing systems; new systems use 140-3. | +| FERPA | 140-2 or 140-3 | Federal-funded educational systems align with 140-2 or 140-3. | +| FedRAMP | 140-2 or 140-3 | FIPS required for encryption; both versions accepted. | +| FISMA | 140-2 or 140-3 | Both versions accepted; agencies adopt existing 140-2 modules. | +| HIPAA | 140-2 or 140-3 | FIPS ensures encryption for ePHI; both versions are valid. | +| HITECH | 140-2 or 140-3 | FIPS use aligns with encryption best practices for ePHI. | +| Intelligence Community | 140-2 transitioning to 140-3 | Current systems mostly use 140-2; newer systems adopt 140-3. | +| Military & Tactical Systems | 140-2 transitioning to 140-3 | 140-2 used widely; transitioning to 140-3 certifications for future tools.| +| NSA CSfC | 140-2 transitioning to 140-3 | NSA accepts 140-2 but prefers newer certifications under 140-3. | +| Nuclear Regulatory Commission | 140-2 or 140-3 | Cryptography for nuclear systems relies on both versions. | +| PCI DSS | 140-2 or 140-3 | Both versions recommended but not mandatory. | +| State and Local Gov Programs | 140-2 or 140-3 | FIPS required for federal grant-funded security systems. | +| TSA | 140-2 or 140-3 | Best practice for cryptographic protection; both versions accepted. | {{< /bootstrap-table >}} -Although FIPS 140 is primarily a North American government certification, it is widely recognized as a global cryptographic baseline. Several countries outside North America align their cryptographic requirements with FIPS, particularly in regulated industries such as finance, defense, and national infrastructure. ### Countries That Base Their Requirements on FIPS +Although FIPS 140 is primarily a North American government cryptographic standard, it is widely recognized as a a global benchmark for cryptographic security. Numerous countries outside North America align their cryptographic requirements with FIPS, especially in regulated sectors such as finance, defense, healthcare, and critical infrastructure. + {{}} -| Country/Region | FIPS Use | -|----------------------|-----------------------------------------------| -| Australia | Referenced for government, defense, and cryptography systems. | -| Canada | Mandatory for federal and sensitive systems. | -| Denmark | Referenced in finance, healthcare, and NATO-related systems. | -| Estonia | Adopted for e-governance and critical systems. | -| Finland | Relied on for defense and NATO collaboration. | -| France | Relied on for defense and secure systems. | -| Germany | Relied on for defense, critical infrastructure, and NATO interoperability. | -| Israel | Trusted in defense, government, and financial systems. | -| Italy | Relied on for defense and financial cryptography. | -| Japan | Referenced in government and financial cryptographic practices. | -| Netherlands | Referenced in finance, healthcare, and NATO cryptography systems. | -| New Zealand | Referenced for government and national cryptography. | -| Poland | Relied on for secure government and NATO-linked communications. | -| Spain | Referenced in NATO interoperability and critical systems. | -| Sweden | Relied on for defense and secure NATO communications. | -| UAE | Trusted in finance, energy, and interoperability with the U.S. cryptography. | -| United Kingdom | Referenced for defense, health, and procurement standards. | -| United States | Mandatory for federal government systems and contractors. | +| Country/Region | FIPS Use | +|----------------|-----------------------------------------------------------------------------| +| Australia | Referenced for government, defense, and cryptography systems. | +| Canada | Mandatory for federal and sensitive systems. | +| Denmark | Referenced in finance, healthcare, and NATO communications. | +| Estonia | Adopted for e-governance and critical systems. | +| Finland | Relied on for defense and NATO communications. | +| France | Relied on for defense and secure systems. | +| Germany | Relied on for defense, critical infrastructure, and NATO communications. | +| Israel | Trusted in defense, government, and financial systems. | +| Italy | Relied on for defense and financial cryptography. | +| Japan | Referenced in government and financial cryptographic practices. | +| Netherlands | Referenced in finance, healthcare, and NATO communications. | +| New Zealand | Referenced for government and national cryptography. | +| Poland | Relied on for secure government and NATO communications. | +| Spain | Referenced in NATO communications and critical systems. | +| Sweden | Relied on for defense and secure NATO communications. | +| UAE | Trusted in finance, energy, and interoperability with the U.S. cryptography.| +| United Kingdom | Referenced for defense, health, and procurement standards. | +| United States | Mandatory for federal government systems and contractors. | {{< /bootstrap-table >}} where: -- Mandatory: used for countries that officially require FIPS compliance (United States, Canada). +- Mandatory: For countries that leagally require FIPS compliance (United States and Canada). -- Relied on: used for countries where FIPS plays a critical role in defense, finance, and secure communication. While not officially mandated, these countries depend on FIPS due to interoperability with NATO systems. +- Relied on: For countries where FIPS is not legally mandated, but plays a critical role in finance, defense, and secure communications. -- Referenced: used when industries or governments incorporate FIPS-certified cryptography as part of their standards but do not enforce it as mandatory. +- Referenced: Governments or industries incorporate FIPS as part of their standards but do not enforce it as mandatory. -- Adopted: used when governments or systems actively use FIPS frameworks for secure collaboration. +- Adopted: Governments or industries actively use FIPS frameworks for secure collaboration. -- Trusted: Used in contexts where FIPS is recognized as a reliable standard for industries such as finance and energy. +- Trusted: FIPS is recognized as a reliable standard for industries such as finance and energy. ## FIPS Compliant or FIPS Validated -FIPS validation is a multistep process that certifies cryptographic modules through formal testing under the [Cryptographic Module Validation Program](https://csrc.nist.gov/Projects/cryptographic-module-validation-program/cmvp-flow) (CMVP). The process is managed by the NIST and requires accredited third-party laboratories to evaluate the cryptographic module. Once a module passes validation, it is officially recognized as FIPS-certified. +FIPS validation is a multistep process that certifies cryptographic modules through formal testing under the [Cryptographic Module Validation Program](https://csrc.nist.gov/Projects/cryptographic-module-validation-program/cmvp-flow) (CMVP). The process is managed by the [NIST](https://csrc.nist.gov/) and requires accredited third-party laboratories to evaluate the cryptographic module. Once a module passes validation, it is officially recognized as FIPS-certified. In contrast, a system that is FIPS compliant adheres to the security requirements outlined in the FIPS standard by using cryptographic algorithms or modules that implement FIPS-approved functions, such as AES for encryption or SHA-256 for hashing. However, compliance alone does not indicate formal validation or certification under the CMVP program. ## FIPS compliance with NGINX Plus -NGINX Plus is **FIPS 140-2 Level 1** and **FIPS 140-3 Level 1 compliant**. +NGINX Plus is **FIPS 140-2 Level 1** and **FIPS 140-3 Level 1 compliant**, provided that the operating system and OpenSSL operating in FIPS mode. NGINX Plus uses the OpenSSL cryptographic module exclusively for all operations relating to the decryption and encryption of SSL/TLS, HTTP/2 and HTTP/3 traffic. -When NGINX Plus is executed on an operating system where a FIPS‑validated OpenSSL cryptographic module is present and FIPS mode is enabled, NGINX Plus is compliant with FIPS 140-2 Level 1/ FIPS 140-3 Level 1 with respect to the decryption and encryption of SSL/TLS, HTTP/2 or HTTP/3 traffic. +When NGINX Plus is executed on an operating system with a FIPS‑validated OpenSSL cryptographic module and FIPS mode is enabled, NGINX Plus is compliant with FIPS 140-2 Level 1/ FIPS 140-3 Level 1 for the decryption and encryption of SSL/TLS, HTTP/2 or HTTP/3 traffic. ## FIPS compliance with NGINX Open Source -While NGINX Plus is tested to work on FIPS-enabled operating systems in FIPS mode, NGINX Open Source is not verified for such environments, especially when third-party builds or modules implementing custom cryptographic functions are used. Misconfigurations, such as enabling TLS 1.0 or using deprecated ciphers (e.g., 3DES), can invalidate FIPS compliance. +While NGINX Plus is tested to work on FIPS-enabled operating systems in FIPS mode, NGINX Open Source is not verified for such environments, especially when third-party builds or modules implementing custom cryptographic functions are used. Compiling NGINX Open Source for FIPS mode may also require additional OS-level dependencies beyond its core requirements, potentially introducing unintended risks. Organizations should consult their security and compliance teams to ensure their configurations meet FIPS requirements. @@ -125,15 +126,15 @@ You also can verify whether your operating system or cryptographic module is FIP ## Verification of Correct Operation of NGINX Plus -The following process describes how to deploy NGINX Plus in a FIPS‑compliant fashion and then verify that the FIPS operations are correctly performed: +The following process describes how to deploy NGINX Plus in a FIPS‑compliant environment and verify that the FIPS operations are functioning correctly. It involves three basic steps: - [Verify](#os-fips-check) if the operating system is running in FIPS mode. If not, [configure](#os-fips-setup) it to enable FIPS mode. -- [Ensure](#openssl-fips-check) that the OpenSSL library is operating in FIPS mode. +- [Verify](#openssl-fips-check) that the OpenSSL library is operating in FIPS mode. -- Run simple checks for [OpenSSL](#openssl-fips-check) and [NGINX Plus](#nginx-plus-fips-check) to ensure FIPS mode. +- Run basic checks for [OpenSSL](#openssl-fips-check) and [NGINX Plus](#nginx-plus-fips-check) to confirm deployment in FIPS mode. -The process uses Red Hat Enterprise Linux (RHEL) release 9.6 as an example, and can be adapted for other Linux operating systems that can be configured in FIPS mode. +The process uses Red Hat Enterprise Linux (RHEL) release 9.6 as an example and can be adapted for other Linux operating systems that can be configured in FIPS mode. ### Step 1: Configure the Operating System to Use FIPS Mode {#os-fips-setup} @@ -249,7 +250,7 @@ The result of the command, showing the MD5 checksum of `/dev/null`: MD5(/dev/null)= d41d8cd98f00b204e9800998ecf8427e ``` -### Step 3: Install NGINX Plus on the Operating System {#nginx-plus-instll} +### Step 4: Install NGINX Plus on the Operating System {#nginx-plus-instll} Follow the [F5 NGINX Plus Installation guide](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-plus/) to install NGINX Plus on the host operating system, either directly from the [NGINX Plus repository](https://account.f5.com/myf5), or by downloading the **nginx-plus** package (**rpm** or **deb** package) onto another system and manually installing it on the host operating system. @@ -298,17 +299,26 @@ Verify that you can access the website using HTTPS from a remote host. Connect t Use `openssl s_client` for this test because it unambiguously confirms which SSL/TLS cipher was negotiated in the connection. After some debugging information (including the cipher selected), the body of the default “Welcome to nginx!” greeting page is displayed. -### Step 4: Verify Compliance with FIPS 140-2 {#fips-2-check} +### Step 5: Verify Compliance with FIPS {#fips-check} + +FIPS 140-2 and 140-3 disallows the use of some cryptographic algorithms, including the Camellia block cipher. In addition to FIPS 140-2, FIPS 140-3 disallows the use of several ciphers and algorithms that were once allowed or still allowed under FIPS 140-2. -FIPS 140-2 disallows the use of some cryptographic algorithms, including the Camellia block cipher. You can test compliance with FIPS 140-2 by issuing SSL/TLS requests with known ciphers on another (non-FIPS-mode) server: +You can test compliance with FIPS 140-2 / 140-3 by issuing SSL/TLS requests with known ciphers on another (non-FIPS-mode) server: #### RC4-MD5 +`RC4-MD5` is considered insecure and deprecated across all modern cryptographic standards. It is disallowed and disabled by default in FIPS-compliant OpenSSL, and TLS 1.2 and 1.3. The SSL handshake always fails. + ```shell (echo "GET /" ; sleep 1) | openssl s_client -connect :443 -cipher RC4-MD5 ``` -This cipher is insecure and is disabled by NGINX Plus by default. The SSL handshake always fails. +Replace `RC4-MD5` with secure, modern FIPS-compliant cipher suites such as: + +- `TLS_RSA_WITH_AES_128_GCM_SHA256` +- `TLS_RSA_WITH_AES_256_GCM_SHA384` +- `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` +- `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` #### CAMELLIA-SHA @@ -316,36 +326,64 @@ This cipher is insecure and is disabled by NGINX Plus by default. The SSL handsh (echo "GET /" ; sleep 1) | openssl s_client -connect :443 -cipher CAMELLIA256-SHA ``` -This cipher is considered secure but is not permitted by the FIPS standard. The SSL handshake fails if the target system is compliant with FIPS 140-2, and succeeds otherwise. +This cipher is considered secure but is not permitted by the FIPS standard. The SSL handshake fails if the target system is compliant with FIPS 140-2 /140-3, and succeeds otherwise. Note that if you attempt to issue the client request on a host running in FIPS mode, it fails because the OpenSSL client cannot use this cipher. -### Step 5: Verify Compliance with FIPS 140-3 {#fips-3-check} - -In addition, FIPS 140-3 disallows the use of several ciphers and algorithms that were once allowed or still allowed under FIPS 140-2: - #### AES256-SHA -Althoguh this cipher is permitted by FIPS 140-2, it is not permitted by FIPS 140-3. The SSL handshake fails in case of FIPS 140-3 and succeeds in case of FIPS 140-2. +The cipher is permitted under FIPS 140-2 as it combines AES encryption with SHA-1. However, under FIPS 140-3, SHA-1 is explicitly disallowed due to its vulnerabilities, such as susceptibility to collision attacks. As a result, the SSL handshake fails under FIPS 140-3 and succeeds under FIPS 140-2: ```shell (echo "GET /" ; sleep 1) | openssl s_client -connect :443 -cipher AES256-SHA ``` +For FIPS 140-3 compliance, you can use alternative cipher suites that leverage SHA-2 or SHA-3 for hashing: + +- AES-GCM-Based Cipher Suites (TLS 1.2): + - `TLS_RSA_WITH_AES_256_GCM_SHA384` + - `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` + +- ChaCha20-Based Cipher Suites (TLS 1.2 or 1.3): + - `TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256` + +- TLS 1.3 Cipher Suites: + - `TLS_AES_256_GCM_SHA384` + - `TLS_AES_128_GCM_SHA256` + - `TLS_CHACHA20_POLY1305_SHA256` + #### 3DES -The `3DES` or Triple DES cipher was once supported but is no longer permitted by NIST as of January 1, 2024. The SSL handshake always fails. +The `3DES` (Triple DES) cipher is allowed under FIPS 140-2, but disallowed under FIPS 140-3. NIST deprecated its use [starting January 1, 2024](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf) due to its reduced security strength (112 bits) and vulnerability to brute-force attacks. + +As a result, the SSL handshake always fails in FIPS-3 compliant environment: ```shell -(echo "GET /" ; sleep 1) | openssl s_client -connect :443 -cipher 3DES +(echo "GET /" ; sleep 1) | openssl s_client -connect :443 -cipher DES-CBC3 ``` +For FIPS 140-3 compliance, you can use AES-Based or ChaCha20-Based cipher suites: -#### RC4 -The `RC4` bulk encryption cipher suite is not allowed in FIPS 140-3. The SSL handshake always fails. +- `TLS_RSA_WITH_AES_128_GCM_SHA256` +- `TLS_RSA_WITH_AES_256_GCM_SHA384` +- `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` +- `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` +- `TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256` + +#### DH and DSA + +Under FIPS 140-2, Diffie-Hellman (DH) and Digital Signature Algorithm (DSA) were permitted with a minimum key size of 1024 bits. However, under FIPS 140-3, the minimum key size for both DH and DSA has been increased to 2048 bits. + +For example, the `TLS_DH_RSA_WITH_AES_128_CBC_SHA` algorithm is FIPS 140-2 compliant, but not FIPS 140-3 compliant due to its use of DH with a key size of less than 2048 bits, CBC mode encryption, and SHA-1 hashing: + +```shell +(echo "GET /" ; sleep 1) | openssl s_client -connect :443 -cipher TLS_DH_RSA_WITH_AES_128_CBC_SHA +``` + +The `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` algorithm is FIPS 140-3 compliant as it uses Elliptic Curve Diffie-Hellman Ephemeral (ECDHE), AES-GCM for encryption, and SHA-256 for hashing: ```shell -(echo "GET /" ; sleep 1) | openssl s_client -connect :443 -cipher RC4 +(echo "GET /" ; sleep 1) | openssl s_client -connect :443 -cipher TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ``` ## Which Ciphers Are Disabled in FIPS Mode? @@ -372,21 +410,6 @@ When you configure NGINX Plus with the `ssl_ciphers ALL` directive, NGINX Plus p - `TLS_RSA_WITH_SEED_CBC_SHA` -In addition, FIPS 140-3 disallows the use of several ciphers and algorithms that were once allowed or still allowed under FIPS 140-2. - -#### 3DES -The `3DES` or Triple DES cipher was once supported but is no longer permitted by NIST as of January 1, 2024. - -#### SHA-1 -The `SHA-1` algorithm is not permitted for cryptographic use under FIPS 140-3. - -#### RC4 -The `RC4` bulk encryption cipher suite is not allowed in FIPS 140-3. - -#### Weak Cipher Suites -In TLS (Transport Layer Security) deployments, weak cipher suites such as `3DES`, `DES`, `RC4`, `ANON`, and `NULL` are not permitted under FIPS 140-3. - - ## Definition of Terms This statement uses the following terms: From 959beac73be5c62fd2341748323de26412e1ecad Mon Sep 17 00:00:00 2001 From: Yaroslav Zhuravlev Date: Wed, 10 Sep 2025 15:49:09 +0100 Subject: [PATCH 5/6] self-review, fips2 vs fips3 tests --- content/nginx/fips-compliance-nginx-plus.md | 171 ++++++++++++++++---- 1 file changed, 136 insertions(+), 35 deletions(-) diff --git a/content/nginx/fips-compliance-nginx-plus.md b/content/nginx/fips-compliance-nginx-plus.md index 32c280c50..4aa004e70 100644 --- a/content/nginx/fips-compliance-nginx-plus.md +++ b/content/nginx/fips-compliance-nginx-plus.md @@ -18,7 +18,7 @@ FIPS 140 is a mandatory cryptographic standard in the United States and Canada f Non-compliance can result to contract loss, restricted project access, fines, or, in severe cases, data breaches compromising personal information or national security. -In addition, non regulated sectors handling sensitive data, such as finance, healthcare, energy, have widely adopted FIPS to strengthen data protection and operational security. +Some industries outside regulatory mandates such as finance, healthcare, energy, also adopt FIPS to enhance data protection and operational security. ### FIPS Compliance Across U.S. Programs, Regulations, and Industries @@ -49,10 +49,21 @@ Currently, both FIPS 140-2 and FIPS 140-3 certifications are accepted. However, | TSA | 140-2 or 140-3 | Best practice for cryptographic protection; both versions accepted. | {{< /bootstrap-table >}} - ### Countries That Base Their Requirements on FIPS -Although FIPS 140 is primarily a North American government cryptographic standard, it is widely recognized as a a global benchmark for cryptographic security. Numerous countries outside North America align their cryptographic requirements with FIPS, especially in regulated sectors such as finance, defense, healthcare, and critical infrastructure. +Although FIPS 140 is primarily a North American government cryptographic standard, it is widely recognized as a global benchmark for cryptographic security. Numerous countries outside North America align their cryptographic requirements with FIPS, especially in regulated sectors such as finance, defense, healthcare, and critical infrastructure. + +There are several types of acceptance: + +- Mandatory: For countries that legally require FIPS compliance (United States and Canada). + +- Relied on: For countries where FIPS is not legally mandated, but plays a critical role in finance, defense, and secure communications. + +- Referenced: Governments or industries incorporate FIPS into their standards but do not enforce it as mandatory. + +- Adopted: Governments or industries actively use FIPS frameworks for secure collaboration. + +- Trusted: FIPS is recognized as a reliable standard for industries such as finance and energy. {{}} | Country/Region | FIPS Use | @@ -77,26 +88,12 @@ Although FIPS 140 is primarily a North American government cryptographic standar | United States | Mandatory for federal government systems and contractors. | {{< /bootstrap-table >}} -where: - -- Mandatory: For countries that leagally require FIPS compliance (United States and Canada). +## FIPS Compliant vs FIPS Validated -- Relied on: For countries where FIPS is not legally mandated, but plays a critical role in finance, defense, and secure communications. - -- Referenced: Governments or industries incorporate FIPS as part of their standards but do not enforce it as mandatory. - -- Adopted: Governments or industries actively use FIPS frameworks for secure collaboration. - -- Trusted: FIPS is recognized as a reliable standard for industries such as finance and energy. - - -## FIPS Compliant or FIPS Validated - -FIPS validation is a multistep process that certifies cryptographic modules through formal testing under the [Cryptographic Module Validation Program](https://csrc.nist.gov/Projects/cryptographic-module-validation-program/cmvp-flow) (CMVP). The process is managed by the [NIST](https://csrc.nist.gov/) and requires accredited third-party laboratories to evaluate the cryptographic module. Once a module passes validation, it is officially recognized as FIPS-certified. +FIPS validation is a formal, multistep process that certifies cryptographic modules through testing under the [Cryptographic Module Validation Program](https://csrc.nist.gov/Projects/cryptographic-module-validation-program/cmvp-flow) (CMVP). The process is managed by the [NIST](https://csrc.nist.gov/) and requires accredited third-party laboratories to evaluate the cryptographic module. Once a module passes validation, it is officially recognized as FIPS-validated, or FIPS-certified. In contrast, a system that is FIPS compliant adheres to the security requirements outlined in the FIPS standard by using cryptographic algorithms or modules that implement FIPS-approved functions, such as AES for encryption or SHA-256 for hashing. However, compliance alone does not indicate formal validation or certification under the CMVP program. - ## FIPS compliance with NGINX Plus NGINX Plus is **FIPS 140-2 Level 1** and **FIPS 140-3 Level 1 compliant**, provided that the operating system and OpenSSL operating in FIPS mode. @@ -156,7 +153,6 @@ For instructions for enabling FIPS mode on other FIPS‑compliant Linux operatin - AlmaLinux: [FIPS Validation for AlmaLinux](https://almalinux.org/blog/2023-09-19-fips-validation-for-almalinux/) - ### Step 2: Verify the Operating System is in FIPS Mode {#os-fips-check} You can verify that the operating system is in FIPS mode and that the version of OpenSSL provided by the operating system vendor is FIPS‑compliant by using the following tests. @@ -330,7 +326,6 @@ This cipher is considered secure but is not permitted by the FIPS standard. The Note that if you attempt to issue the client request on a host running in FIPS mode, it fails because the OpenSSL client cannot use this cipher. - #### AES256-SHA The cipher is permitted under FIPS 140-2 as it combines AES encryption with SHA-1. However, under FIPS 140-3, SHA-1 is explicitly disallowed due to its vulnerabilities, such as susceptibility to collision attacks. As a result, the SSL handshake fails under FIPS 140-3 and succeeds under FIPS 140-2: @@ -339,7 +334,7 @@ The cipher is permitted under FIPS 140-2 as it combines AES encryption with SHA- (echo "GET /" ; sleep 1) | openssl s_client -connect :443 -cipher AES256-SHA ``` -For FIPS 140-3 compliance, you can use alternative cipher suites that leverage SHA-2 or SHA-3 for hashing: +For FIPS 140-3 compliance, alternative cipher suites that leverage SHA-2 or SHA-3 for hashing can be used: - AES-GCM-Based Cipher Suites (TLS 1.2): - `TLS_RSA_WITH_AES_256_GCM_SHA384` @@ -362,7 +357,7 @@ As a result, the SSL handshake always fails in FIPS-3 compliant environment: ```shell (echo "GET /" ; sleep 1) | openssl s_client -connect :443 -cipher DES-CBC3 ``` -For FIPS 140-3 compliance, you can use AES-Based or ChaCha20-Based cipher suites: +For FIPS 140-3 compliance, AES-Based or ChaCha20-Based cipher suites can be used: - `TLS_RSA_WITH_AES_128_GCM_SHA256` - `TLS_RSA_WITH_AES_256_GCM_SHA384` @@ -388,27 +383,133 @@ The `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` algorithm is FIPS 140-3 compliant as ## Which Ciphers Are Disabled in FIPS Mode? -The FIPS 140-2 standard only permits a [subset of the typical SSL and TLS ciphers](https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402annexa.pdf). +The FIPS 140-2 standard only permits a [subset of the typical SSL and TLS ciphers](https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402annexa.pdf), while FIPS 140-3 [extends this requirements](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf) to enforce stricter cryptographic algorithms. -In the following test, the ciphers presented by NGINX Plus are surveyed using the [Qualys SSL server test](https://www.ssllabs.com/ssltest). In its default configuration, with the `ssl_ciphers HIGH:!aNULL:!MD5` directive, NGINX Plus presents the following ciphers to SSL/TLS clients: +In the following test, the ciphers presented by NGINX Plus are surveyed using the `nmap` utility (installed separately). In its default configuration, with the [`ssl_ciphers HIGH:!aNULL:!MD5`](nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_ciphers) directive, NGINX Plus presents the following ciphers to SSL/TLS clients: -Ciphers presented by NGINX Plus to clients when in non-FIPS mode +```shell +nmap --script ssl-enum-ciphers -p 443 +``` + +The output of the command for NGINX Plus running on Red Hat Enterprise Linux 9 without FIPS enabled: + +```shell +PORT STATE SERVICE +443/tcp open https +| ssl-enum-ciphers: +| TLSv1.2: +| ciphers: +| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A +| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A +| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A +| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A +| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A +| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A +| TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256 (secp256r1) - A +| TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384 (secp256r1) - A +| TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (secp256r1) - A +| TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 (secp256r1) - A +| TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A +| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A +| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A +| TLS_RSA_WITH_AES_128_CCM (rsa 2048) - A +| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A +| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A +| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A +| TLS_RSA_WITH_AES_256_CCM (rsa 2048) - A +| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A +| TLS_RSA_WITH_ARIA_128_GCM_SHA256 (rsa 2048) - A +| TLS_RSA_WITH_ARIA_256_GCM_SHA384 (rsa 2048) - A +| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A +| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 (rsa 2048) - A +| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A +| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 (rsa 2048) - A +| compressors: +| NULL +| cipher preference: client +| TLSv1.3: +| ciphers: +| TLS_AKE_WITH_AES_128_CCM_SHA256 (ecdh_x25519) - A +| TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A +| TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A +| TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A +| cipher preference: client +|_ least strength: A +``` -When FIPS mode is enabled on the host operating system, the two ciphers that use the Camellia block cipher (`TLS_RSA_WITH_CAMELLIA_128_CBC_SHA` and `TLS_RSA_WITH_CAMELLIA_256_CBC_SHA`) are removed: +When FIPS 140-3 mode is enabled, NGINX Plus presents the following ciphers to SSL/TLS clients: -Ciphers presented by NGINX Plus to clients when in FIPS mode +```shell +PORT STATE SERVICE +443/tcp open https +| ssl-enum-ciphers: +| TLSv1.2: +| ciphers: +| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A +| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A +| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A +| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A +| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A +| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A +| compressors: +| NULL +| cipher preference: client +| TLSv1.3: +| ciphers: +| TLS_AKE_WITH_AES_128_CCM_SHA256 (secp256r1) - A +| TLS_AKE_WITH_AES_128_GCM_SHA256 (secp256r1) - A +| TLS_AKE_WITH_AES_256_GCM_SHA384 (secp256r1) - A +| cipher preference: client +|_ least strength: A +``` + +Based on the results above, the following ciphers are disallowed under FIPS 140-3 compliance: -When you configure NGINX Plus with the `ssl_ciphers ALL` directive, NGINX Plus presents all the relevant ciphers available in the OpenSSL cryptographic module to the client. FIPS mode disables the following ciphers: +1. Camellia-Based Ciphers: FIPS compliance requires cryptographic algorithms to be validated by NIST, and Camellia is not NIST-approved despite being recognized by ISO/IEC standards. -- `TLS_ECDH_anon_WITH_RC4_128_SHA` -- `TLS_ECDHE_RSA_WITH_RC4_128_SHA` +- `TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256` +- `TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384` - `TLS_RSA_WITH_CAMELLIA_128_CBC_SHA` +- `TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256` - `TLS_RSA_WITH_CAMELLIA_256_CBC_SHA` -- `TLS_RSA_WITH_IDEA_CBC_SHA` -- `TLS_RSA_WITH_RC4_128_MD5` -- `TLS_RSA_WITH_RC4_128_SHA` -- `TLS_RSA_WITH_SEED_CBC_SHA` +- `TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256` + +2. ARIA-Based Ciphers: similar to Camellia, ARIA is not a NIST-approved algorithm and is therefore excluded from FIPS compliance. + +- `TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256` +- `TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384` +- `TLS_RSA_WITH_ARIA_128_GCM_SHA256` +- `TLS_RSA_WITH_ARIA_256_GCM_SHA384` + +3. RSA Key Exchange Ciphers: static RSA key exchange lacks Forward Secrecy, allowing decryption of past traffic if the private key is compromised, thus disallowed in FIPS mode. + +- `TLS_RSA_WITH_AES_128_CBC_SHA` +- `TLS_RSA_WITH_AES_128_CBC_SHA256` +- `TLS_RSA_WITH_AES_128_GCM_SHA256` +- `TLS_RSA_WITH_AES_256_CBC_SHA` +- `TLS_RSA_WITH_AES_256_CBC_SHA256` +- `TLS_RSA_WITH_AES_256_GCM_SHA384` + +4. CBC Mode Ciphers (Non-AEAD: CBC is vulnerable to padding oracle attacks (e.g., POODLE, Lucky13), making it insecure. FIPS 140-3 prioritizes AEAD modes like AES-GCM and AES-CCM. + +- `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA` +- `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256` +- `TLS_RSA_WITH_AES_128_CBC_SHA` +- `TLS_RSA_WITH_AES_128_CBC_SHA256` +- `TLS_RSA_WITH_AES_256_CBC_SHA` +- `TLS_RSA_WITH_AES_256_CBC_SHA256` + +5. ChaCha20-Poly1305: it is not a NIST-approved algorithm and is excluded from FIPS compliance. FIPS exclusively permits algorithms such as `AES-GCM` and `AES-CCM`. + +- `TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256` + +6. AES-CCM Variants: + +- `TLS_RSA_WITH_AES_128_CCM` +- `TLS_RSA_WITH_AES_256_CCM` + +It is also possible to use the [Qualys SSL server test](https://www.ssllabs.com/ssltest) to verify the ciphers presented by NGINX Plus to SSL/TLS clients. ## Definition of Terms From a39342e7e12a746cc87d68bbbe16ce300826b801 Mon Sep 17 00:00:00 2001 From: Yaroslav Zhuravlev Date: Fri, 12 Sep 2025 19:00:52 +0100 Subject: [PATCH 6/6] self-review --- content/nginx/fips-compliance-nginx-plus.md | 138 +++++++++----------- 1 file changed, 59 insertions(+), 79 deletions(-) diff --git a/content/nginx/fips-compliance-nginx-plus.md b/content/nginx/fips-compliance-nginx-plus.md index 4aa004e70..d61966731 100644 --- a/content/nginx/fips-compliance-nginx-plus.md +++ b/content/nginx/fips-compliance-nginx-plus.md @@ -10,17 +10,17 @@ type: ## What is FIPS -The Federal Information Processing Standard (FIPS), issued by the [U.S. National Institute of Standards and Technology](https://www.nist.gov/) (NIST), defines mandatory security requirements for cryptographic modules used in federal IT systems. [FIPS 140-2](https://csrc.nist.gov/pubs/fips/140-2/upd2/final), and its successor [FIPS 140-3](https://csrc.nist.gov/pubs/fips/140-3/final), establish strict standards to protect sensitive but unclassified information, including government communications and citizen data. +The Federal Information Processing Standard (FIPS), issued by the [U.S. National Institute of Standards and Technology](https://www.nist.gov/) (NIST), defines mandatory security requirements for cryptographic modules used in federal IT systems. [FIPS 140-2](https://csrc.nist.gov/pubs/fips/140-2/upd2/final), and its successor [FIPS 140-3](https://csrc.nist.gov/pubs/fips/140-3/final), establish strict standards to protect sensitive information, including government communications and citizen data. -## Why FIPS-140 Matters +## Why FIPS-140 matters FIPS 140 is a mandatory cryptographic standard in the United States and Canada for federal agencies, their contractors, and many regulated industries. Non-compliance can result to contract loss, restricted project access, fines, or, in severe cases, data breaches compromising personal information or national security. -Some industries outside regulatory mandates such as finance, healthcare, energy, also adopt FIPS to enhance data protection and operational security. +Some industries such as finance, healthcare, energy, also adopt FIPS to enhance data protection and operational security. -### FIPS Compliance Across U.S. Programs, Regulations, and Industries +### FIPS compliance in U.S. Currently, both FIPS 140-2 and FIPS 140-3 certifications are accepted. However, FIPS 140-2 is being phased out as part of the [FIPS 140-3 transition plan](https://csrc.nist.gov/projects/fips-140-3-transition-effort). After September 22, 2026, only FIPS 140-3 certifications will be recognized. Organizations are encouraged to migrate to FIPS 140-3 to meet updated cryptographic security requirements. @@ -49,22 +49,10 @@ Currently, both FIPS 140-2 and FIPS 140-3 certifications are accepted. However, | TSA | 140-2 or 140-3 | Best practice for cryptographic protection; both versions accepted. | {{< /bootstrap-table >}} -### Countries That Base Their Requirements on FIPS +### FIPS compliance in other countries Although FIPS 140 is primarily a North American government cryptographic standard, it is widely recognized as a global benchmark for cryptographic security. Numerous countries outside North America align their cryptographic requirements with FIPS, especially in regulated sectors such as finance, defense, healthcare, and critical infrastructure. -There are several types of acceptance: - -- Mandatory: For countries that legally require FIPS compliance (United States and Canada). - -- Relied on: For countries where FIPS is not legally mandated, but plays a critical role in finance, defense, and secure communications. - -- Referenced: Governments or industries incorporate FIPS into their standards but do not enforce it as mandatory. - -- Adopted: Governments or industries actively use FIPS frameworks for secure collaboration. - -- Trusted: FIPS is recognized as a reliable standard for industries such as finance and energy. - {{}} | Country/Region | FIPS Use | |----------------|-----------------------------------------------------------------------------| @@ -88,19 +76,17 @@ There are several types of acceptance: | United States | Mandatory for federal government systems and contractors. | {{< /bootstrap-table >}} -## FIPS Compliant vs FIPS Validated +## FIPS compliant vs FIPS validated -FIPS validation is a formal, multistep process that certifies cryptographic modules through testing under the [Cryptographic Module Validation Program](https://csrc.nist.gov/Projects/cryptographic-module-validation-program/cmvp-flow) (CMVP). The process is managed by the [NIST](https://csrc.nist.gov/) and requires accredited third-party laboratories to evaluate the cryptographic module. Once a module passes validation, it is officially recognized as FIPS-validated, or FIPS-certified. +FIPS validation is a formal multistep process that certifies cryptographic modules through testing under the [Cryptographic Module Validation Program](https://csrc.nist.gov/Projects/cryptographic-module-validation-program/cmvp-flow) (CMVP). The process is managed by the [NIST](https://csrc.nist.gov/) and requires accredited third-party laboratories to evaluate the cryptographic module. Once a module passes validation, it is officially recognized as FIPS-validated (FIPS-certified). -In contrast, a system that is FIPS compliant adheres to the security requirements outlined in the FIPS standard by using cryptographic algorithms or modules that implement FIPS-approved functions, such as AES for encryption or SHA-256 for hashing. However, compliance alone does not indicate formal validation or certification under the CMVP program. +FIPS compliance indicates that a system or a module claims to meet the FIPS requirements, however, it has not been officially tested or certified under the CMVP program. ## FIPS compliance with NGINX Plus -NGINX Plus is **FIPS 140-2 Level 1** and **FIPS 140-3 Level 1 compliant**, provided that the operating system and OpenSSL operating in FIPS mode. - -NGINX Plus uses the OpenSSL cryptographic module exclusively for all operations relating to the decryption and encryption of SSL/TLS, HTTP/2 and HTTP/3 traffic. +NGINX Plus is **FIPS 140-2 Level 1** and **FIPS 140-3 Level 1 compliant**, provided that the operating system and the OpenSSL library are operating in FIPS mode. -When NGINX Plus is executed on an operating system with a FIPS‑validated OpenSSL cryptographic module and FIPS mode is enabled, NGINX Plus is compliant with FIPS 140-2 Level 1/ FIPS 140-3 Level 1 for the decryption and encryption of SSL/TLS, HTTP/2 or HTTP/3 traffic. +NGINX Plus relies exclusively on the operating system’s FIPS-validated OpenSSL library for all SSL/TLS, HTTP/2, and HTTP/3 encryption and decryption operations. ## FIPS compliance with NGINX Open Source @@ -121,7 +107,7 @@ Several operating system vendors have obtained FIPS 140-2 Level 1 and 140-3 Leve You also can verify whether your operating system or cryptographic module is FIPS-validated using the [NIST database search tool](https://csrc.nist.gov/Projects/cryptographic-module-validation-program/validated-modules/search). -## Verification of Correct Operation of NGINX Plus +## Verification of correct operation of NGINX Plus The following process describes how to deploy NGINX Plus in a FIPS‑compliant environment and verify that the FIPS operations are functioning correctly. It involves three basic steps: @@ -133,7 +119,7 @@ The following process describes how to deploy NGINX Plus in a FIPS‑compliant e The process uses Red Hat Enterprise Linux (RHEL) release 9.6 as an example and can be adapted for other Linux operating systems that can be configured in FIPS mode. -### Step 1: Configure the Operating System to Use FIPS Mode {#os-fips-setup} +### Step 1: Configure the operating system to use FIPS mode {#os-fips-setup} For the purposes of the following demonstration, we installed and configured a RHEL 9.6 server. The [Red Hat FIPS documentation](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/chap-federal_standards_and_regulations#sec-Enabling-FIPS-Mode) explains how to switch the operating system between FIPS mode and non‑FIPS mode by editing the boot options and restarting the system. @@ -153,7 +139,7 @@ For instructions for enabling FIPS mode on other FIPS‑compliant Linux operatin - AlmaLinux: [FIPS Validation for AlmaLinux](https://almalinux.org/blog/2023-09-19-fips-validation-for-almalinux/) -### Step 2: Verify the Operating System is in FIPS Mode {#os-fips-check} +### Step 2: Verify the operating system is in FIPS mode {#os-fips-check} You can verify that the operating system is in FIPS mode and that the version of OpenSSL provided by the operating system vendor is FIPS‑compliant by using the following tests. @@ -196,7 +182,7 @@ The output of the command shows that FIPS is running: FIPS mode is enabled. ``` -### Step 3: Verify the OpenSSL is in FIPS Mode {#openssl-fips-check} +### Step 3: Verify the OpenSSL is in FIPS mode {#openssl-fips-check} **Determine the OpenSSL FIPS Provider is active**: This test verifies the correct version of OpenSSL and that the OpenSSL FIPS Provider is active: @@ -246,7 +232,7 @@ The result of the command, showing the MD5 checksum of `/dev/null`: MD5(/dev/null)= d41d8cd98f00b204e9800998ecf8427e ``` -### Step 4: Install NGINX Plus on the Operating System {#nginx-plus-instll} +### Step 4: Install NGINX Plus on the operating system {#nginx-plus-instll} Follow the [F5 NGINX Plus Installation guide](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-plus/) to install NGINX Plus on the host operating system, either directly from the [NGINX Plus repository](https://account.f5.com/myf5), or by downloading the **nginx-plus** package (**rpm** or **deb** package) onto another system and manually installing it on the host operating system. @@ -295,7 +281,7 @@ Verify that you can access the website using HTTPS from a remote host. Connect t Use `openssl s_client` for this test because it unambiguously confirms which SSL/TLS cipher was negotiated in the connection. After some debugging information (including the cipher selected), the body of the default “Welcome to nginx!” greeting page is displayed. -### Step 5: Verify Compliance with FIPS {#fips-check} +### Step 5: Verify compliance with FIPS {#nginx-plus-fips-check} FIPS 140-2 and 140-3 disallows the use of some cryptographic algorithms, including the Camellia block cipher. In addition to FIPS 140-2, FIPS 140-3 disallows the use of several ciphers and algorithms that were once allowed or still allowed under FIPS 140-2. @@ -309,7 +295,7 @@ You can test compliance with FIPS 140-2 / 140-3 by issuing SSL/TLS requests with (echo "GET /" ; sleep 1) | openssl s_client -connect :443 -cipher RC4-MD5 ``` -Replace `RC4-MD5` with secure, modern FIPS-compliant cipher suites such as: +For FIPS compliance, alternative cipher suites can be used such as: - `TLS_RSA_WITH_AES_128_GCM_SHA256` - `TLS_RSA_WITH_AES_256_GCM_SHA384` @@ -324,8 +310,6 @@ Replace `RC4-MD5` with secure, modern FIPS-compliant cipher suites such as: This cipher is considered secure but is not permitted by the FIPS standard. The SSL handshake fails if the target system is compliant with FIPS 140-2 /140-3, and succeeds otherwise. -Note that if you attempt to issue the client request on a host running in FIPS mode, it fails because the OpenSSL client cannot use this cipher. - #### AES256-SHA The cipher is permitted under FIPS 140-2 as it combines AES encryption with SHA-1. However, under FIPS 140-3, SHA-1 is explicitly disallowed due to its vulnerabilities, such as susceptibility to collision attacks. As a result, the SSL handshake fails under FIPS 140-3 and succeeds under FIPS 140-2: @@ -381,7 +365,7 @@ The `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` algorithm is FIPS 140-3 compliant as (echo "GET /" ; sleep 1) | openssl s_client -connect :443 -cipher TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ``` -## Which Ciphers Are Disabled in FIPS Mode? +## Ciphers disabled in FIPS Mode The FIPS 140-2 standard only permits a [subset of the typical SSL and TLS ciphers](https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402annexa.pdf), while FIPS 140-3 [extends this requirements](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf) to enforce stricter cryptographic algorithms. @@ -465,75 +449,71 @@ PORT STATE SERVICE Based on the results above, the following ciphers are disallowed under FIPS 140-3 compliance: -1. Camellia-Based Ciphers: FIPS compliance requires cryptographic algorithms to be validated by NIST, and Camellia is not NIST-approved despite being recognized by ISO/IEC standards. +- Camellia-Based Ciphers: FIPS compliance requires cryptographic algorithms to be validated by NIST, and Camellia is not NIST-approved despite being recognized by ISO/IEC standards. -- `TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256` -- `TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384` -- `TLS_RSA_WITH_CAMELLIA_128_CBC_SHA` -- `TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256` -- `TLS_RSA_WITH_CAMELLIA_256_CBC_SHA` -- `TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256` + - `TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256` + - `TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384` + - `TLS_RSA_WITH_CAMELLIA_128_CBC_SHA` + - `TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256` + - `TLS_RSA_WITH_CAMELLIA_256_CBC_SHA` + - `TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256` -2. ARIA-Based Ciphers: similar to Camellia, ARIA is not a NIST-approved algorithm and is therefore excluded from FIPS compliance. +- ARIA-Based Ciphers: similar to Camellia, ARIA is not a NIST-approved algorithm and is therefore excluded from FIPS compliance. -- `TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256` -- `TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384` -- `TLS_RSA_WITH_ARIA_128_GCM_SHA256` -- `TLS_RSA_WITH_ARIA_256_GCM_SHA384` + - `TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256` + - `TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384` + - `TLS_RSA_WITH_ARIA_128_GCM_SHA256` + - `TLS_RSA_WITH_ARIA_256_GCM_SHA384` -3. RSA Key Exchange Ciphers: static RSA key exchange lacks Forward Secrecy, allowing decryption of past traffic if the private key is compromised, thus disallowed in FIPS mode. +- RSA Key Exchange Ciphers: static RSA key exchange lacks Forward Secrecy, allowing decryption of past traffic if the private key is compromised, thus disallowed in FIPS mode. -- `TLS_RSA_WITH_AES_128_CBC_SHA` -- `TLS_RSA_WITH_AES_128_CBC_SHA256` -- `TLS_RSA_WITH_AES_128_GCM_SHA256` -- `TLS_RSA_WITH_AES_256_CBC_SHA` -- `TLS_RSA_WITH_AES_256_CBC_SHA256` -- `TLS_RSA_WITH_AES_256_GCM_SHA384` + - `TLS_RSA_WITH_AES_128_CBC_SHA` + - `TLS_RSA_WITH_AES_128_CBC_SHA256` + - `TLS_RSA_WITH_AES_128_GCM_SHA256` + - `TLS_RSA_WITH_AES_256_CBC_SHA` + - `TLS_RSA_WITH_AES_256_CBC_SHA256` + - `TLS_RSA_WITH_AES_256_GCM_SHA384` -4. CBC Mode Ciphers (Non-AEAD: CBC is vulnerable to padding oracle attacks (e.g., POODLE, Lucky13), making it insecure. FIPS 140-3 prioritizes AEAD modes like AES-GCM and AES-CCM. +- CBC Mode Ciphers (Non-AEAD: CBC is vulnerable to padding oracle attacks (e.g., POODLE, Lucky13), making it insecure. FIPS 140-3 prioritizes AEAD modes like AES-GCM and AES-CCM. -- `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA` -- `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256` -- `TLS_RSA_WITH_AES_128_CBC_SHA` -- `TLS_RSA_WITH_AES_128_CBC_SHA256` -- `TLS_RSA_WITH_AES_256_CBC_SHA` -- `TLS_RSA_WITH_AES_256_CBC_SHA256` + - `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA` + - `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256` + - `TLS_RSA_WITH_AES_128_CBC_SHA` + - `TLS_RSA_WITH_AES_128_CBC_SHA256` + - `TLS_RSA_WITH_AES_256_CBC_SHA` + - `TLS_RSA_WITH_AES_256_CBC_SHA256` -5. ChaCha20-Poly1305: it is not a NIST-approved algorithm and is excluded from FIPS compliance. FIPS exclusively permits algorithms such as `AES-GCM` and `AES-CCM`. +- ChaCha20-Poly1305: it is not a NIST-approved algorithm and is excluded from FIPS compliance. FIPS exclusively permits algorithms such as `AES-GCM` and `AES-CCM`. -- `TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256` + - `TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256` -6. AES-CCM Variants: +- AES-CCM Variants: -- `TLS_RSA_WITH_AES_128_CCM` -- `TLS_RSA_WITH_AES_256_CCM` + - `TLS_RSA_WITH_AES_128_CCM` + - `TLS_RSA_WITH_AES_256_CCM` -It is also possible to use the [Qualys SSL server test](https://www.ssllabs.com/ssltest) to verify the ciphers presented by NGINX Plus to SSL/TLS clients. +You can also use the [Qualys SSL server test](https://www.ssllabs.com/ssltest) to verify the ciphers presented by NGINX Plus to SSL/TLS clients. -## Definition of Terms +## Conclusion + +NGINX Plus can be used to decrypt and encrypt SSL/TLS‑encrypted network traffic in deployments that require FIPS 140-2 Level 1 or FIPS 140-3 Level 1 compliance. -This statement uses the following terms: +The process described above may be used to verify that NGINX Plus is operating in conformance with the FIPS 140-2 Level 1 and FIPS 140-3 Level 1 standards. + +## Definition of terms - **Cryptographic module**: The OpenSSL software, comprised of libraries of FIPS‑validated algorithms that can be used by other applications. - **Cryptographic boundary**: The operational functions that use FIPS‑validated algorithms. For NGINX Plus, the cryptographic boundary includes all functionality that is implemented by the [`http_auth_jwt`](https://nginx.org/en/docs/http/ngx_http_auth_jwt_module.html), [`http_ssl`](https://nginx.org/en/docs/http/ngx_http_ssl_module.html), [`http_v2`](https://nginx.org/en/docs/http/ngx_http_v2_module.html), [`http_v3`](https://nginx.org/en/docs/http/ngx_http_v3_module.html), [`mail_ssl`](https://nginx.org/en/docs/mail/ngx_mail_ssl_module.html), and [`stream_ssl`](https://nginx.org/en/docs/stream/ngx_stream_ssl_module.html) modules. These modules implement SSL and TLS operations for inbound and outbound connections which use HTTP, HTTP/2, HTTP/3, TCP, and mail protocols. -- **NGINX Plus**: The NGINX Plus software application developed by NGINX, Inc. and delivered in binary format from NGINX servers. +- **NGINX Plus**: The NGINX Plus software application developed by F5, Inc. and delivered in binary format from F5 servers. -- **FIPS mode**: When the operating system is configured to run in FIPS mode, the OpenSSL cryptographic module operates in a mode that has been validated to be in compliance with FIPS 140-2 Level 2. Most operating systems do not run in FIPS mode by default, so explicit configuration is necessary to enable FIPS mode. +- **FIPS mode**: When the operating system is configured to run in FIPS mode, the OpenSSL cryptographic module operates in a mode that has been validated to be in compliance with FIPS 140-2 Level 1 or FIPS 140-3 Level 1. Most operating systems do not run in FIPS mode by default, so explicit configuration is necessary to enable FIPS mode. - **FIPS validated**: A component of the OpenSSL cryptographic module (the OpenSSL FIPS Object Module) is formally validated by an authorized certification laboratory. The validation holds if the module is built from source with no modifications to the source or build process. The implementation of FIPS mode that is present in operating system vendors’ distributions of OpenSSL contains this validated module. -- **FIPS compliant**: NGINX Plus is compliant with FIPS 140-2 Level 1 and FIPS 140-3 Level 1 within the cryptographic boundary when used with a FIPS‑validated OpenSSL cryptographic module on an operating system running in FIPS mode. - - -## Conclusion - -NGINX Plus can be used to decrypt and encrypt SSL/TLS‑encrypted network traffic in deployments that require FIPS 140-2 Level 1 or FIPS 140-3 Level 1 compliance. - -The process described above may be used to verify that NGINX Plus is operating in conformance with the FIPS 140-2 Level 1 and FIPS 140-3 Level 1 standards. - +- **FIPS compliant**: NGINX Plus is compliant with FIPS 140-2 Level 1 and FIPS 140-3 Level 1 within the cryptographic boundary when used with a FIPS‑validated OpenSSL cryptographic module on an operating system running in FIPS mode. ## See also: