FIPS mode and TLS - OpenSSLWiki (2024)

This page discusses the use of FIPS with OpenSSL 1.0.x. It is NOT relevant to the FIPS provider in OpenSSL 3.0 or above.

The new SP800-131A and FIPS 186-4 restrictions on algorithms and key sizes complicatethe use of ciphersuites for TLS considerably. This page is intended to answer thequestion "can I configure an OpenSSL cipherstring for TLS to comply with the new FIPS restrictions?".

This discussion assumes use of a "FIPS capable" OpenSSL 1.0.1f or later.

A new security framework in development for future versions will make enforcing these typesof restrictions easier and the algorithm restrictions are performed all in one place.

1 Quick Summary
2 Detailed discussion
- 2.1 TLS 1.0 and 1.1
- 2.2 TLS 1.2
- 2.3 Cipherstrings
- 2.4 A quick overview of TLS
  - 2.4.1 Digests in TLS
  - 2.4.2 Digital Signatures in TLS
- 2.5 What about versions of OpenSSL prior to 1.0.1f?

Quick Summary[edit]

The preferred cipherstring for OpenSSL 1.0.1f+ for all versions of TLS subject to the new FIPSrestrictions is:

'TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL'

However, multiple caveats apply as discussed below.

Workarounds for OpenSSL releases prior to 1.0.1f are discussed below.

Detailed discussion[edit]

The general rule is you can't use SHA1 for digital signatures any more nora combination like MD5+SHA1. You *can* use SHA1 for HMAC so there's no need toforce the use of SHA256 HMAC ciphersuites.

A cipherstring in OpenSSL also known as a "cipher list" https://www.openssl.org/docs/apps/ciphers.html#CIPHER_STRINGSA cipherstring in OpenSSL is a compact notation for a set of cryptographic algorithms(public key, symmetric key, and digest algorithms) in order of preference.

The cipherstring notation is discussed at https://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMATBriefly, a cipherstring is a series of elements each designating either a specific ciphersuite or a set ofciphersuites. The "+" operator designates a logical and operation, so "element1+element1" represents thatset of ciphersuites containing the algorithms in both element1 and element2. The "!" operator permanentlyall the algorithms in the following element.

TLS 1.0 and 1.1[edit]

All TLS 1.0/1.1 authenticated PFS (Perfect Forward Secrecy) ciphersuites use SHA1 alone or MD5+SHA1. Thatleaves only unauthenticated ones (which are vulnerable to MiTM so we discountthem) or those using static keys. Theoretically that would permit RSA, DH orECDH keys in certificates but in practice everyone uses RSA.

The corresponding cipherstring is:

openssl ciphers -v 'kRSA+FIPS:!TLSv1.2'AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1

That cipherstring specifies three possible ciphersuites allowable in FIPS mode for TLS 1.0 and 1.1.The RSA key in the certificate has to be of suitable size(2048 bits minimum) as do all other keys in the chain and none of the CAs cansign using SHA1. Also those kRSA ciphersuites are allowed forserver certificates only; client authentication is never allowedwith the new rules for TLS 1.0 and 1.1.

In a real application when FIPS mode is enabled then only FIPS ciphersuites are allowed no matter what you use in the string. So in FIPS mode"kRSA:!TLSv1.2" will be functionally equivalent to "kRSA+FIPS!TLSv1.2".

Note the "TLSv1.2" string was only added to OpenSSL recently, as of OpenSSL 1.0.1f.It designates the ciphers for TLSv1.2 subject to the FIPS 140-2 and FIPS 186-4restrictions.

Note the cipherstring 'FIPS:!TLSv1.2' would also allow fixed DH and fixed ECDHcertificates but those are not encountered in the wild.The key exchange component "kRSA" specifies just those algorithms that support RSA key exchange.

TLS 1.2[edit]

TLS 1.2 provides more options as the signature can use an algorithm otherthan SHA1. "kRSA+FIPS" specifies those ciphersuites that use RSA key exchange, including TLS v1.2, *and*are allowed in FIPS mode, and including anonymous ones which may be undesirable:

openssl ciphers -v 'kRSA+FIPS'AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEADAES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEADAES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1

The ephemeral key for the now permitted PFS keys must be at least 2048 bits (DH)or 256 bits (ECDH) in size. Anything supporting ECDH will probably set P-256 asa default so that should be OK (Apache does).

There's a snag though. The ciphersuite ECDH-RSA-AES128-SHA can (outside FIPS) beused for TLS 1.0 and later whereas in FIPS mode it can only be used for TLS v1.2. ATLS client can't advertise ciphersuites in that way (i.e. you can use this forTLS1.2 only and nothing earlier) so you're left with the situation where a FIPScompliant client might say it wants ECDH-RSA-AES128-SHAand TLS 1.2 and the server only supports TLS 1.0 so it will choke when it tries touse the prohibited ciphersuite+version combination. Servers are fine becausethey can theoretically select based on version (except in practice OpenSSL doesn't support that).

Cipherstrings[edit]

Commentary on what the cipherstrings components mean and their relevance:

"TLSv1.2": list of ciphersuites only allowed for TLS 1.2. This means if TLS 1.2is negotiated they can be used and if not they won't. They also happen to bepermitted by FIPS 186-4 because TLS 1.2 can use signature algorithms strongerthat SHA1. That means that it is "safe" to include this in a cipher stringbecause (a) they are compliant with FIPS 186-4 in for TLS 1.2 and (b) they cannever be used for TLS 1.1 or 1.0.

"kRSA": list of ciphersuites which support RSA key exchange. Because TLS 1.1 and1.0 can only use SHA1+MD5 in signatures these are the only ones allowed becausethey don't use signatures.

"FIPS": list of ciphersuites allowed in FIPS mode excluding those offering noencryption. This is for informational purposes only because if you *are* in FIPSmode you can only use those ciphersuites anyway (but including the no encryptionones).

The lists above all include ciphersuites which you wouldn't normally use: noencryption or no authentication. So those need to be disabled. This is done byappending '!eNULL:!aNULL': this means "disable any ciphersuites present whichinclude no encryption or authentication".

So combining these we get the following cipher string in FIPS mode:

'TLSv1.2:kRSA:!eNULL:!aNULL'

which with the functionally redundant "+FIPS" qualifiers is equivant to:

'TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL'

Without the "+FIPS" qualifiers and outside FIPS mode you'll will see weak export gradeciphersuites which would be disabled in FIPS mode. Those can be seen with:

openssl ciphers -v 'TLSv1.2:kRSA:!eNULL:!aNULL'

To see the actual set of ciphersuites in FIPS mode, without the explicit "+FIPS" qualifiers,do:

OPENSSL_FIPS=1 openssl ciphers -v 'TLSv1.2:kRSA:!eNULL:!aNULL'

So in summary "in FIPS mode use the cipherstring 'TLSv1.2:kRSA:!eNULL:!aNULL'"

Note this important disclaimer though: This cipherstring *only* restricts the ciphersuites to thosenot explicitly excluded by FIPS 186-4. There are other conditions which must beenforced such as key size, permitted curves and permitted signature algorithms.Just because a ciphersuite has been negotiated in this range does not guaranteedcompliance.

The "FIPS capable" OpenSSL does not currently provide a means to automatically enforce thenew FIPS 186-4 restrictions.

A quick overview of TLS[edit]

The primary purpose of the handshake is to enable both peers to securely obtaina shared secret value called the pre-master secret. They then use that togenerate session keys (encryption and MAC) which are used for the exchange ofactual application data. The handshake is the only place public key algorithmsare used.

In the case of PFS ciphersuites both ends generate a temporary key (ECDH or DH)and exchange the public bits with each other. They use the algorithm to generatethe shared DH/ECDH secret value which is used later on. The new FIPS restrictions interfere withthis because those keys have to be large enough. For ECDH an extension can beused to ensure this. For DH you just have to hope the server has a big enoughkey and abort if not.

For anonymous algorithms that's all you get. They are vulnerable to man in themiddle (MitM) attacks and so are rarely used.

In the real world algorithms include authentication. In those the server digitallysigns its ECDH or DH key using the key in its certificate. This is to ensure thetemporary ECDH or DH key can't be forged. It is that digital signature that isimportant here and the one which the new FIPS restrictions disrupt.

How that temporary key is signed depends on the cipher suite and the key in theserver's certificate. The whole process is called server authentication.

In the case of TLS 1.0 and 1.1 that signature uses a MD5+SHA1 hybrid for RSAkeys and just SHA1 for DSA and ECDSA. That's why PFS is prohibited by the new FIPSrules: there is no option but to use SHA1.

In the case of TLS 1.2 any valid combination can be used and the MD5+SHA1 hybrid is nolonger present for RSA. RSA just uses the same signature format thatcertificates use (PKCS#1).

For TLS 1.2 the client sends the set of signature algorithms it supports inpreference order in the supported signature algorithms extensions. The serverthen selects one and uses that for that signature. For new FIPS it would justuse SHA256 as a minimum or abort the connection if the client only supportedSHA1 (unlikely).

Client authentication in TLS is a secondary concern. In this case the clientsigns some data related to the handshake and sends the result back. The serverthen checks that signature.

As with server authentication TLS 1.1/1.0 has to use either MD5+SHA1 for RSA orjust SHA1 for other algorithms. So client authentication violates the new FIPSrestrictions and cannot be used for TLs 1.0/1.1.

TLS 1.2 removes the restriction to SHA1. In this case the server sends back thealgorithms it supports and the client selects one. Again SHA256 orbetter s needed to comply with new FIPS restrictions.

Next consider the non-PFS case. We consider RSAkey exchange only as is the only practical option. This is completely different from PFS. Inthis case the client generates the pre master secret and encrypts it using theservers key. The server decrypts it and then uses that to complete thehandshake. No additional signing is used here so no place for SHA1 to be used.The server is authenticated because if it didn't have the right key it couldn'tdecrypt the pre-master secret. It's a bit unusual in that authentication (whichis normally associated with signatures) is performed using an RSA decryptionoperation.

Some further discussion in case that wasn't confusing enough:

Some people say that it is implied that TLS 1.1 and 1.0 must use SHA1 indigital signatures in all certificates. If so thenTLS 1.1 and 1.0 can never be compliant with new FIPS.

Assuming that is not true, what does it mean in practice? Aa public webserver would require a certificate signed by CAs thatuse SHA256 minimum and large enough keys. Not a trivialtask in itself.

Aside from that, problems will be encountered if your server needs to use anythingoutside of the new FIPS restrictions (e.g. to talk to otherclients). Some older browsers (e.g. IE on XP is one which isstill very common) don't support SHA2 at all. So they'll fail when they talk tothat server because the can't verify the signatures.

TLS 1.2 is a bit better, at least in theory. The supported signatures should apply to thewhole certificate chain. So a client advertising only SHA1+RSA receive achain supporting SHA1+RSA only (if the server has one) and a client supporting SHA256+RSAwill receive a "new FIPS" friendly chain.

However, in practice that requirement is generally ignored and implementations serve up whateverchain is configured regardless of signature algorithms sent by the clientbecause many implementers consider that a slly restriction. For interoperability OpenSSL issimilarly lax if a "strict" option isn't set. In fact configuring multiplechains like that can't be directly done in OpenSSL without application supportwhich nothing other than s_server can currently handle.

Digests in TLS[edit]

There are different purposes that digest algorithms are put to.

In TLS 1.2 something called the supported signature algorithms extensiondetermines the supported digests as a public key + algorithm pair. It's thatusage that FIPS 186-4 (and SP800-57) has an impact on. So you can't use RSA+SHA1any more. For digital signatures the strength of SHA1 is at most 80 bits: it canbe less with a weak key.

That digital signature is used to maintain the integrity of the handshakemessages and certificate chains in PFS ciphersuites: basically server and clientauthentication.

For TLS 1.2 you can specify any digest to be used to maintain handshakeintegrity for digital signatures: for TLS 1.1 and below you could only useSHA1+MD5. It's that reason why PFS ciphersuites are banned in TLS 1.1 and below.

Digests use HMAC. For HMAC use the key strength is the digest length so SHA1 is 160 bits.

Before TLS 1.2 all cipher suites used SHA1 HMAC (or in legacy cases MD5) for theHMAC.

TLS 1.2 introduced some ciphersuites which used SHA256 and SHA384 for the HMACand the AEAD ones like AES-GCM which have a mac as part of the algorithm itself.

Note that TLS 1.2 also permits all the ciphersuites for TLS 1.1, 1.0 too.For details see Table 2 and 3 in SP800-57.

Those tables make a lot more sense when you realise for digital signatures it'shalf the digest size. So SHA1 is 20 bytes which is 160 bits and so 80 bits ofstrength so it only appears in the "80 bits" box for digital signatures. Whereasfor other uses it is the full digest size so SHA1 appears in the 80, 112 and 128bit boxes.

Unfortunately the FIPS terminology unnecessarily obfuscated the issue. It wouldhave been easier to just say in SP800-57 that SHA1 HMAC is 160 bitsof equivalent security instead of placing it in the :Security Strenght 128" rowof Table 3.

TLS 1.2 can use SHA1 in two different places. One is the signature algorithms oncertificates: i.e. the algorithm the CA signs with. The second place istemporary key signature (server authentication) as described below.

Digital Signatures in TLS[edit]

There are three places digital signatures are used in TLS.

1. The signatures on certificates.

The certificates' signatures are set by the CA so to comply with new FIPSwhatever else you do you need a certificate chain that uses SHA256 at least.

2. Server Key Exchange.

The Server Key Exchange message contains a signature in any authenticated PFSciphersuite. The algorithm used depends on the version of TLS.

For TLS 1.1 and 1.0 the algorithm is either a MD5+SHA1 hybrid (RSA) or SHA1(DSA, ECDSA). Both of these are prohibited by new FIPS so TLS 1.1 and 1.0authenticated PFS ciphersuites are not allowed.

For TLS 1.2 any appropriate algorithm can be used to sign Server Key Exchangemessages. So PFS authenticated ciphersuites *are* allowed under new FIPS as longas SHA1 is not used to sign Server Key Exchange. MD5 is of course a double no-no.

3. Certificate Verify.

The Certificate Verify message is used whenever client authentication is enabledfor any applicable ciphersuite (not just PFS). The same digest algorithms areused as Server Key Exchange.

Therefore new FIPS and TLS 1.1 and 1.0 prohibits client authentication outrightin *any* ciphersuite.

TLS 1.2 is more flexible and can use any appropriate algorithm so clientauthentication is permitted as long as SHA1 and MD5 are not used.

What about versions of OpenSSL prior to 1.0.1f?[edit]

The "TLSv1.2" ciphersuite designation was added at 1.0.1f. For earlier versions ofOpenSSL the current equivalent of the cipherstring

'TLSv1.2:kRSA:!eNULL:!aNULL'

can be "brute forced" as the unwieldy

'ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:ADH-AES256-GCM-SHA384:ADH-AES256-SHA256:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:AES256-GCM-SHA384:AES256-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:ADH-AES128-GCM-SHA256:ADH-AES128-SHA256:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:AES128-GCM-SHA256:AES128-SHA256:NULL-SHA256:kRSA:!eNULL:!aNULL'

However, as new ciphersuites get added to the 'TLSv1.2' ciphersuite that brute forceequivalent might end up not beingequivalent any more.

Since TLSv1.2 only ciphers use SHA256, SHA384 and AES in GCM mode so one string is:

'AESGCM:SHA384:SHA256'

There are other ways to get the same effect. One is to disable any ciphers whichuse SHA1. So "FIPS:-SHA" is currently equivalent to "FIPS+TLSv1.2". The use ofthe "-SHA" is necessary here because it only *temporarily* disables SHA1 MACs.That means you can do: "FIPS:-SHA:FIPS+kRSA" to add back the RSA key exchangeciphersuites that use SHA1. Contrast that with using "!SHA" instead which permanentlyremoves SHA1 from the cipherstring.

FAQs

Is TLS FIPS approved? ›

TLS implementation must use FIPS 140-3/FIPS 140-23 validated cryptographic modules in order to achieve FIPS compliance. NIST maintains a list of FIPS Cryptographic Modules. A cryptographic module may either be an embedded component of a product or application, or an individual product in and of itself.

How to turn on TLS 1.0 TLS 1.1 and TLS 1.2 in advanced settings? ›

Click the Tools icon (gear symbol) in the upper right hand corner of the browser and click Internet Options. In the Internet Options window, select the Advanced tab. In the Advanced tab, under Settings, scroll down to the Security section. In the Security section, check Use TLS 1.1 and Use TLS 1.2.

How do I know if OpenSSL is in FIPS mode? ›

Verify the operating system

View the parameters that were passed to the kernel. Run the following command: cat /proc/cmdline. ...
Verify that your kernel is configured for FIPS. Run the following command: sysctl crypto.fips_enabled. ...
Verify that the OpenSSL package is FIPS certified. Run the following command: openssl version.

Find Out More ›

How do I test FIPS mode? ›

Check the status of IPsec running in FIPS mode for your operating system.

For Red Hat Linux, run the following command: ipsec status | grep fips. Your output might resemble the following text if FIPS is enabled: 000 fips mode=enabled;
For Ubuntu, run the following command: ipsec statusall | grep -i fips.

Discover More ›

Is TLS 1.2 to become the minimum for FIPS endpoints? ›

November 10, 2022: This project was successfully completed in March 2021. TLS 1.2 is now the minimum version supported for all connections to AWS FIPS service endpoints. Note we will be implementing the same policy for non-FIPS endpoints by June 2023.

What versions of OpenSSL are FIPS-compliant? ›

The Module meets the overall security level requirements of Level 1. The Module's software versions for this validation are 3.0. 8 and 3.0.

How to check if TLS 1.1 is enabled? ›

Google Chrome

Open Google Chrome.
Click Alt F and select Settings.
Scroll down and select Show advanced settings...
Scroll down to the Network section and click on Change proxy settings...
Select the Advanced tab.
Scroll down to Security category, manually check the option box for Use TLS 1.1 and Use TLS 1.2.
Click OK.

More items...

Nov 1, 2023

View Details ›

How to tell if TLS 1.2 is enabled? ›

-Press the Windows key + R to start Run, type regedit, and press Enter or click OK. -If you can't find any of the keys or if their values are not correct, then TLS 1.2 is not enabled.

View Details ›

How do I know if TLS 1.0 is enabled or disabled? ›

To check for TLS 1.0 you could run Wireshark, on the server, and filter for that kind of traffic ( ssl. handshake. version==0x0301 ). If there is not much then disable TLS 1.0 with IISCrypto, as Alpharius suggested, and test all applications function normally.

Why enable FIPS mode? ›

Encryption modules for information technology and computer security programs that are running in FIPS mode will perform Federal Information Processing Standards-compliant functions such as key generation, encryption, and decryption.

Get More Info ›

How do I know if my SSL certificate is FIPS compliant? ›

Navigate to Infrastructure, SSL Configuration. The SSL Configuration dialog displays. Look at the FIPS Approved field for the Embedded web server and the Administrative UI.

Read On ›

How do I change FIPS mode? ›

Turn FIPS mode on or off

Log in to Administration Console.
Click Settings > Core System Settings > Configurations.
Select Enable FIPS to enable FIPS mode or deselect it to disable FIPS mode.
Click OK and restart the application server.

Learn More Now ›

Why we're not recommending FIPS mode? ›

The non-FIPS versions have been available much longer (and so are used more widely) and are usually much faster. If FIPS mode is enabled, the non-FIPS algorithms throw an error and the application fails. So basically, if FIPS mode is enabled, most applications using cryptographic functionality fail.

FIPS mode and TLS - OpenSSLWiki (2024)

Contents

Quick Summary[edit]

Detailed discussion[edit]

TLS 1.0 and 1.1[edit]

TLS 1.2[edit]

Cipherstrings[edit]

A quick overview of TLS[edit]

Digests in TLS[edit]

Digital Signatures in TLS[edit]

What about versions of OpenSSL prior to 1.0.1f?[edit]

FAQs

Is TLS FIPS approved? ›

How do I know if my SSL certificate is FIPS compliant? ›

References