https://wiki.openssl.org/index.php?title=FIPS_mode_and_TLS&feed=atom&action=historyFIPS mode and TLS - Revision history2024-03-29T15:59:43ZRevision history for this page on the wikiMediaWiki 1.35.6https://wiki.openssl.org/index.php?title=FIPS_mode_and_TLS&diff=3229&oldid=prevMatt: Added sentence about the new FIPS module2024-02-02T08:32:31Z<p>Added sentence about the new FIPS module</p>
<table class="diff diff-contentalign-left diff-editfont-monospace" data-mw="interface">
<col class="diff-marker" />
<col class="diff-content" />
<col class="diff-marker" />
<col class="diff-content" />
<tr class="diff-title" lang="en">
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td>
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 08:32, 2 February 2024</td>
</tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l1" >Line 1:</td>
<td colspan="2" class="diff-lineno">Line 1:</td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;">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.</ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;"></ins></div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>The new SP800-131A and FIPS 186-4 restrictions on algorithms and key sizes complicate</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>The new SP800-131A and FIPS 186-4 restrictions on algorithms and key sizes complicate</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>the use of ciphersuites for TLS considerably. This page is intended to answer the</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>the use of ciphersuites for TLS considerably. This page is intended to answer the</div></td></tr>
</table>Matthttps://wiki.openssl.org/index.php?title=FIPS_mode_and_TLS&diff=1565&oldid=prevJwalton: Added FIPS category.2014-03-12T11:37:59Z<p>Added FIPS category.</p>
<table class="diff diff-contentalign-left diff-editfont-monospace" data-mw="interface">
<col class="diff-marker" />
<col class="diff-content" />
<col class="diff-marker" />
<col class="diff-content" />
<tr class="diff-title" lang="en">
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td>
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 11:37, 12 March 2014</td>
</tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l407" >Line 407:</td>
<td colspan="2" class="diff-lineno">Line 407:</td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>ciphersuites that use SHA1. Contrast that with using "!SHA" instead which permanently</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>ciphersuites that use SHA1. Contrast that with using "!SHA" instead which permanently</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>removes SHA1 from the cipherstring.</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>removes SHA1 from the cipherstring.</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;"></ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;">[[Category:FIPS 140]]</ins></div></td></tr>
</table>Jwaltonhttps://wiki.openssl.org/index.php?title=FIPS_mode_and_TLS&diff=1471&oldid=prevStevem: First draft of large new page2014-02-10T13:53:14Z<p>First draft of large new page</p>
<p><b>New page</b></p><div>The new SP800-131A and FIPS 186-4 restrictions on algorithms and key sizes complicate<br />
the use of ciphersuites for TLS considerably. This page is intended to answer the<br />
question "can I configure an OpenSSL cipherstring for TLS to comply with the new FIPS restrictions?". <br />
<br />
This discussion assumes use of a "FIPS capable" OpenSSL 1.0.1f or later.<br />
<br />
A new security framework in development for future versions will make enforcing these types<br />
of restrictions easier and the algorithm restrictions are performed all in one place.<br />
<br />
== Quick Summary ==<br />
<br />
The preferred cipherstring for OpenSSL 1.0.1f+ for all versions of TLS subject to the new FIPS<br />
restrictions is:<br />
<pre><br />
'TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL'<br />
</pre><br />
However, multiple caveats apply as discussed below.<br />
<br />
Workarounds for OpenSSL releases prior to 1.0.1f are discussed below.<br />
<br />
== Detailed discussion ==<br />
<br />
The general rule is you can't use SHA1 for digital signatures any more nor<br />
a combination like MD5+SHA1. You *can* use SHA1 for HMAC so there's no need to<br />
force the use of SHA256 HMAC ciphersuites.<br />
<br />
A cipherstring in OpenSSL also known as a "cipher list" <br />
https://www.openssl.org/docs/apps/ciphers.html#CIPHER_STRINGS<br />
A cipherstring in OpenSSL is a compact notation for a set of cryptographic algorithms<br />
(public key, symmetric key, and digest algorithms) in order of preference.<br />
<br />
The cipherstring notation is discussed at https://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT<br />
Briefly, a cipherstring is a series of elements each designating either a specific ciphersuite or a set of<br />
ciphersuites. The "+" operator designates a logical and operation, so "element1+element1" represents that<br />
set of ciphersuites containing the algorithms in both element1 and element2. The "!" operator permanently<br />
all the algorithms in the following element.<br />
<br />
=== TLS 1.0 and 1.1 ===<br />
<br />
All TLS 1.0/1.1 authenticated PFS (Perfect Forward Secrecy) ciphersuites use SHA1 alone or MD5+SHA1. That<br />
leaves only unauthenticated ones (which are vulnerable to MiTM so we discount<br />
them) or those using static keys. Theoretically that would permit RSA, DH or<br />
ECDH keys in certificates but in practice everyone uses RSA.<br />
<br />
The corresponding cipherstring is:<br />
<pre><br />
openssl ciphers -v 'kRSA+FIPS:!TLSv1.2'<br />
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1<br />
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1<br />
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1<br />
</pre><br />
That cipherstring specifies three possible ciphersuites allowable in FIPS mode for TLS 1.0 and 1.1.<br />
The RSA key in the certificate has to be of suitable size<br />
(2048 bits minimum) as do all other keys in the chain and none of the CAs can<br />
sign using SHA1. Also those kRSA ciphersuites are allowed for<br />
server certificates only; client authentication is never allowed<br />
with the new rules for TLS 1.0 and 1.1.<br />
<br />
In a real application when FIPS mode is enabled then only <br />
FIPS ciphersuites are allowed no matter what you use in the string. So in FIPS mode<br />
"kRSA:!TLSv1.2" will be functionally equivalent to "kRSA+FIPS!TLSv1.2".<br />
<br />
Note the "TLSv1.2" string was only added to OpenSSL recently, as of OpenSSL 1.0.1f.<br />
It designates the ciphers for TLSv1.2 subject to the FIPS 140-2 and FIPS 186-4<br />
restrictions.<br />
<br />
Note the cipherstring 'FIPS:!TLSv1.2' would also allow fixed DH and fixed ECDH<br />
certificates but those are not encountered in the wild.<br />
The key exchange component "kRSA" specifies just those algorithms that support RSA key exchange.<br />
<br />
=== TLS 1.2 ===<br />
<br />
TLS 1.2 provides more options as the signature can use an algorithm other<br />
than SHA1. <br />
"kRSA+FIPS" specifies those ciphersuites that use RSA key exchange, including TLS v1.2, *and*<br />
are allowed in FIPS mode, and including anonymous ones which may be undesirable:<br />
<pre><br />
openssl ciphers -v 'kRSA+FIPS'<br />
AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD<br />
AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256<br />
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1<br />
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1<br />
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD<br />
AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256<br />
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1<br />
</pre><br />
The ephemeral key for the now permitted PFS keys must be at least 2048 bits (DH)<br />
or 256 bits (ECDH) in size. Anything supporting ECDH will probably set P-256 as<br />
a default so that should be OK (Apache does).<br />
<br />
There's a snag though. The ciphersuite ECDH-RSA-AES128-SHA can (outside FIPS) be<br />
used for TLS 1.0 and later whereas in FIPS mode it can only be used for TLS v1.2. A<br />
TLS client can't advertise ciphersuites in that way (i.e. you can use this for<br />
TLS1.2 only and nothing earlier) so you're left with the situation where a FIPS<br />
compliant client might say it wants ECDH-RSA-AES128-SHA<br />
and TLS 1.2 and the server only supports TLS 1.0 so it will choke when it tries to<br />
use the prohibited ciphersuite+version combination. Servers are fine because<br />
they can theoretically select based on version (except in practice OpenSSL doesn't support that).<br />
<br />
If that wasn't enough there's another complication. For TLS v1.2 you have to<br />
restrict the supported signature algorithms to exclude SHA1, allowing only<br />
SHA256 and above. There is no way to do that in OpenSSL 1.0.1 clients.<br />
Similarly the supported EC curves have to be restricted to exclude some which are<br />
of insufficient field size.<br />
<br />
In summary: it's a bloody mess.<br />
<br />
The list of allowable ciphers for all versions of TLS, 1.0/1/1/1.2 is 'TLSv1.2:kRSA'<br />
which includes those with no encryption or no authentication which are generally<br />
undesirable and should be excluded. In full with explicit "+FIPS" qualification that becomes:<br />
<pre><br />
'TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL'<br />
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD<br />
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD<br />
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384<br />
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384<br />
DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD<br />
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD<br />
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256<br />
DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256<br />
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD<br />
ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD<br />
ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA384<br />
ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA384<br />
AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD<br />
AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256<br />
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD<br />
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD<br />
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256<br />
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256<br />
DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD<br />
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD<br />
DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256<br />
DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128) Mac=SHA256<br />
ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD<br />
ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD<br />
ECDH-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA256<br />
ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA256<br />
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD<br />
AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256<br />
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1<br />
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1<br />
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1<br />
</pre><br />
What does this ciphersuite specification mean in practice?<br />
<br />
If the peer supports TLS v1.2 it will use a TLS v1.2 ciphersuite which is FIPS<br />
186-4 compliant (with the curve and signature restrictions I mentioned) or<br />
non-PFS RSA otherwise.<br />
<br />
If the peer only supports TLS 1.1 or 1.0 it will fall back to the non-PFS RSA<br />
ciphersuites which again will be FIPS 186-4 compliant subject to the silly key<br />
and certificate signing restrictions.<br />
<br />
The ciphersuite (for 1.0.1f+) of 'TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL'<br />
will satisfy FIPS 186-4 for any version of TLS 1.0/1.1/1.2 with caveats as noted.<br />
<br />
To specify a list of allowable ciphers for TLS 1.0/1.1 only append !TLSv1.2 which permanently deletes<br />
those which are only usable for TLS v1.2, giving 'kRSA+FIPS:!TLSv1.2'.<br />
<br />
=== Cipherstrings ===<br />
<br />
Commentary on what the cipherstrings components mean and their relevance:<br />
<br />
"TLSv1.2": list of ciphersuites only allowed for TLS 1.2. This means if TLS 1.2<br />
is negotiated they can be used and if not they won't. They also happen to be<br />
permitted by FIPS 186-4 because TLS 1.2 can use signature algorithms stronger<br />
that SHA1. That means that it is "safe" to include this in a cipher string<br />
because (a) they are compliant with FIPS 186-4 in for TLS 1.2 and (b) they can<br />
never be used for TLS 1.1 or 1.0.<br />
<br />
"kRSA": list of ciphersuites which support RSA key exchange. Because TLS 1.1 and<br />
1.0 can only use SHA1+MD5 in signatures these are the only ones allowed because<br />
they don't use signatures.<br />
<br />
"FIPS": list of ciphersuites allowed in FIPS mode excluding those offering no<br />
encryption. This is for informational purposes only because if you *are* in FIPS<br />
mode you can only use those ciphersuites anyway (but including the no encryption<br />
ones).<br />
<br />
The lists above all include ciphersuites which you wouldn't normally use: no<br />
encryption or no authentication. So those need to be disabled. This is done by<br />
appending '!eNULL:!aNULL': this means "disable any ciphersuites present which<br />
include no encryption or authentication".<br />
<br />
So combining these we get the following cipher string in FIPS mode:<br />
<pre><br />
'TLSv1.2:kRSA:!eNULL:!aNULL'<br />
</pre><br />
which with the functionally redundant "+FIPS" qualifiers is equivant to:<br />
<pre><br />
'TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL'<br />
</pre><br />
Without the "+FIPS" qualifiers and outside FIPS mode you'll will see weak export grade<br />
ciphersuites which would be disabled in FIPS mode. Those can be seen with:<br />
<pre><br />
openssl ciphers -v 'TLSv1.2:kRSA:!eNULL:!aNULL'<br />
</pre><br />
To see the actual set of ciphersuites in FIPS mode, without the explicit "+FIPS" qualifiers,<br />
do:<br />
<pre><br />
OPENSSL_FIPS=1 openssl ciphers -v 'TLSv1.2:kRSA:!eNULL:!aNULL'<br />
</pre><br />
So in summary "in FIPS mode use the cipherstring 'TLSv1.2:kRSA:!eNULL:!aNULL'"<br />
<br />
Note this important disclaimer though: This cipherstring *only* restricts the ciphersuites to those<br />
not explicitly excluded by FIPS 186-4. There are other conditions which must be<br />
enforced such as key size, permitted curves and permitted signature algorithms.<br />
Just because a ciphersuite has been negotiated in this range does not guaranteed<br />
compliance.<br />
<br />
The "FIPS capable" OpenSSL does not currently provide a means to automatically enforce the<br />
new FIPS 186-4 restrictions.<br />
<br />
=== A quick overview of TLS ===<br />
<br />
The primary purpose of the handshake is to enable both peers to securely obtain<br />
a shared secret value called the pre-master secret. They then use that to<br />
generate session keys (encryption and MAC) which are used for the exchange of<br />
actual application data. The handshake is the only place public key algorithms<br />
are used.<br />
<br />
In the case of PFS ciphersuites both ends generate a temporary key (ECDH or DH)<br />
and exchange the public bits with each other. They use the algorithm to generate<br />
the shared DH/ECDH secret value which is used later on. The new FIPS restrictions interfere with<br />
this because those keys have to be large enough. For ECDH an extension can be<br />
used to ensure this. For DH you just have to hope the server has a big enough<br />
key and abort if not.<br />
<br />
For anonymous algorithms that's all you get. They are vulnerable to man in the<br />
middle (MitM) attacks and so are rarely used.<br />
<br />
In the real world algorithms include authentication. In those the server digitally<br />
signs its ECDH or DH key using the key in its certificate. This is to ensure the<br />
temporary ECDH or DH key can't be forged. It is that digital signature that is<br />
important here and the one which the new FIPS restrictions disrupt.<br />
<br />
How that temporary key is signed depends on the cipher suite and the key in the<br />
server's certificate. The whole process is called server authentication.<br />
<br />
In the case of TLS 1.0 and 1.1 that signature uses a MD5+SHA1 hybrid for RSA<br />
keys and just SHA1 for DSA and ECDSA. That's why PFS is prohibited by the new FIPS<br />
rules: there is no option but to use SHA1.<br />
<br />
In the case of TLS 1.2 any valid combination can be used and the MD5+SHA1 hybrid is no<br />
longer present for RSA. RSA just uses the same signature format that<br />
certificates use (PKCS#1).<br />
<br />
For TLS 1.2 the client sends the set of signature algorithms it supports in<br />
preference order in the supported signature algorithms extensions. The server<br />
then selects one and uses that for that signature. For new FIPS it would just<br />
use SHA256 as a minimum or abort the connection if the client only supported<br />
SHA1 (unlikely).<br />
<br />
Client authentication in TLS is a secondary concern. In this case the client<br />
signs some data related to the handshake and sends the result back. The server<br />
then checks that signature.<br />
<br />
As with server authentication TLS 1.1/1.0 has to use either MD5+SHA1 for RSA or<br />
just SHA1 for other algorithms. So client authentication violates the new FIPS<br />
restrictions and cannot be used for TLs 1.0/1.1.<br />
<br />
TLS 1.2 removes the restriction to SHA1. In this case the server sends back the<br />
algorithms it supports and the client selects one. Again SHA256 or<br />
better s needed to comply with new FIPS restrictions.<br />
<br />
Next consider the non-PFS case. We consider RSA<br />
key exchange only as is the only practical option. This is completely different from PFS. In<br />
this case the client generates the pre master secret and encrypts it using the<br />
servers key. The server decrypts it and then uses that to complete the<br />
handshake. No additional signing is used here so no place for SHA1 to be used.<br />
The server is authenticated because if it didn't have the right key it couldn't<br />
decrypt the pre-master secret. It's a bit unusual in that authentication (which<br />
is normally associated with signatures) is performed using an RSA decryption<br />
operation.<br />
<br />
Some further discussion in case that wasn't confusing enough:<br />
<br />
Some people say that it is implied that TLS 1.1 and 1.0 must use SHA1 in<br />
digital signatures in all certificates. If so then<br />
TLS 1.1 and 1.0 can never be compliant with new FIPS.<br />
<br />
Assuming that is not true, what does it mean in practice? A<br />
a public webserver would require a certificate signed by CAs that<br />
use SHA256 minimum and large enough keys. Not a trivial<br />
task in itself.<br />
<br />
Aside from that, problems will be encountered if your server needs to use anything<br />
outside of the new FIPS restrictions (e.g. to talk to other<br />
clients). Some older browsers (e.g. IE on XP is one which is<br />
still very common) don't support SHA2 at all. So they'll fail when they talk to<br />
that server because the can't verify the signatures.<br />
<br />
TLS 1.2 is a bit better, at least in theory. The supported signatures should apply to the<br />
whole certificate chain. So a client advertising only SHA1+RSA receive a<br />
chain supporting SHA1+RSA only (if the server has one) and a client supporting SHA256+RSA<br />
will receive a "new FIPS" friendly chain.<br />
<br />
However, in practice that requirement is generally ignored and implementations serve up whatever<br />
chain is configured regardless of signature algorithms sent by the client<br />
because many implementers consider that a slly restriction. For interoperability OpenSSL is<br />
similarly lax if a "strict" option isn't set. In fact configuring multiple<br />
chains like that can't be directly done in OpenSSL without application support<br />
which nothing other than s_server can currently handle.<br />
<br />
==== Digests in TLS ====<br />
<br />
There are different purposes that digest algorithms are put to.<br />
<br />
In TLS 1.2 something called the supported signature algorithms extension<br />
determines the supported digests as a public key + algorithm pair. It's that<br />
usage that FIPS 186-4 (and SP800-57) has an impact on. So you can't use RSA+SHA1<br />
any more. For digital signatures the strength of SHA1 is at most 80 bits: it can<br />
be less with a weak key.<br />
<br />
That digital signature is used to maintain the integrity of the handshake<br />
messages and certificate chains in PFS ciphersuites: basically server and client<br />
authentication.<br />
<br />
For TLS 1.2 you can specify any digest to be used to maintain handshake<br />
integrity for digital signatures: for TLS 1.1 and below you could only use<br />
SHA1+MD5. It's that reason why PFS ciphersuites are banned in TLS 1.1 and below.<br />
<br />
Digests use HMAC. For HMAC use the key strength is the digest length so SHA1 is 160 bits.<br />
<br />
Before TLS 1.2 all cipher suites used SHA1 HMAC (or in legacy cases MD5) for the<br />
HMAC.<br />
<br />
TLS 1.2 introduced some ciphersuites which used SHA256 and SHA384 for the HMAC<br />
and the AEAD ones like AES-GCM which have a mac as part of the algorithm itself.<br />
<br />
Note that TLS 1.2 also permits all the ciphersuites for TLS 1.1, 1.0 too.<br />
For details see Table 2 and 3 in SP800-57.<br />
<br />
Those tables make a lot more sense when you realise for digital signatures it's<br />
half the digest size. So SHA1 is 20 bytes which is 160 bits and so 80 bits of<br />
strength so it only appears in the "80 bits" box for digital signatures. Whereas<br />
for other uses it is the full digest size so SHA1 appears in the 80, 112 and 128<br />
bit boxes.<br />
<br />
Unfortunately the FIPS terminology unnecessarily obfuscated the issue. It would<br />
have been easier to just say in SP800-57 that SHA1 HMAC is 160 bits<br />
of equivalent security instead of placing it in the :Security Strenght 128" row<br />
of Table 3. <br />
<br />
TLS 1.2 can use SHA1 in two different places. One is the signature algorithms on<br />
certificates: i.e. the algorithm the CA signs with. The second place is<br />
temporary key signature (server authentication) as described below.<br />
<br />
==== Digital Signatures in TLS ====<br />
<br />
There are three places digital signatures are used in TLS.<br />
<br />
1. The signatures on certificates.<br />
<br />
The certificates' signatures are set by the CA so to comply with new FIPS<br />
whatever else you do you need a certificate chain that uses SHA256 at least.<br />
<br />
2. Server Key Exchange.<br />
<br />
The Server Key Exchange message contains a signature in any authenticated PFS<br />
ciphersuite. The algorithm used depends on the version of TLS.<br />
<br />
For TLS 1.1 and 1.0 the algorithm is either a MD5+SHA1 hybrid (RSA) or SHA1<br />
(DSA, ECDSA). Both of these are prohibited by new FIPS so TLS 1.1 and 1.0<br />
authenticated PFS ciphersuites are not allowed.<br />
<br />
For TLS 1.2 any appropriate algorithm can be used to sign Server Key Exchange<br />
messages. So PFS authenticated ciphersuites *are* allowed under new FIPS as long<br />
as SHA1 is not used to sign Server Key Exchange. MD5 is of course a double no-no.<br />
<br />
3. Certificate Verify.<br />
<br />
The Certificate Verify message is used whenever client authentication is enabled<br />
for any applicable ciphersuite (not just PFS). The same digest algorithms are<br />
used as Server Key Exchange.<br />
<br />
Therefore new FIPS and TLS 1.1 and 1.0 prohibits client authentication outright<br />
in *any* ciphersuite.<br />
<br />
TLS 1.2 is more flexible and can use any appropriate algorithm so client<br />
authentication is permitted as long as SHA1 and MD5 are not used.<br />
<br />
=== What about versions of OpenSSL prior to 1.0.1f? ===<br />
<br />
The "TLSv1.2" ciphersuite designation was added at 1.0.1f. For earlier versions of<br />
OpenSSL the current equivalent of the cipherstring<br />
<pre><br />
'TLSv1.2:kRSA:!eNULL:!aNULL'<br />
</pre><br />
can be "brute forced" as the unwieldy<br />
<pre><br />
'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'<br />
</pre><br />
However, as new ciphersuites get added to the 'TLSv1.2' ciphersuite that brute force<br />
equivalent might end up not being<br />
equivalent any more.<br />
<br />
Since TLSv1.2 only ciphers use SHA256, SHA384 and AES in GCM mode so one string is:<br />
<pre><br />
'AESGCM:SHA384:SHA256'<br />
</pre><br />
There are other ways to get the same effect. One is to disable any ciphers which<br />
use SHA1. So "FIPS:-SHA" is currently equivalent to "FIPS+TLSv1.2". The use of<br />
the "-SHA" is necessary here because it only *temporarily* disables SHA1 MACs.<br />
That means you can do: "FIPS:-SHA:FIPS+kRSA" to add back the RSA key exchange<br />
ciphersuites that use SHA1. Contrast that with using "!SHA" instead which permanently<br />
removes SHA1 from the cipherstring.</div>Stevem