339267 - PSM should have a FIPS mode that uses only TLS and only FIPS approved cipher suites

Status: RESOLVED DUPLICATE of bug 106604

(Core :: Security: PSM, enhancement, P2)

Description

[Wan-Teh Chang]

When we are in the FIPS mode of operation, we should
only use TLS, but not SSL 3.0 or SSL 2.0.  This requirement
is given in FIPS 140-2 Implementation Guide 7.1 "Acceptable
Key Establishment Protocols":

  * SSL: only SSL v3.1 is acceptable for use in the FIPS
    mode.
  * TLS and EAP-TLS: these two protocols can be used in
    the FIPS mode. ...
  ...
  * SSL: all versions of the SSL protocol except SSL v3.1,
    are not to be used in the FIPS mode. ...
    Note 1: SSL v3.1 is allowed, as it is equivalent to
    TLS v1.0.

Furthermore, only the cipher suites whose 'isFIPS' flag is
true can be used in the FIPS mode.  Call SSLCipherSuiteInfo
and then examine the isFIPS flag in the returned
SSLCipherSuiteInfo structure.

Call PK11_IsFIPS to determine if we are in the FIPS mode.

Comment 1

[Kai Engert (:KaiE:)]

Is the application responsible for setting the allowed set of ciphers?

Should NSS do it by itself, at the time it is switched into FIPS mode?

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

AFAIK, "FIPS mode" is a propety of one PKCS#11 module.
It is not a property of libSSL (libSSL has no "FIPS mode").
It is not a property of NSS as a whole, but only of one 
particular PKCS#11 module that is part of NSS.  

I guess the application can decide for itself whether it has 
a "FIPS mode" for itself, a mode in which it attempts to use
no non-FIPS encryption.  If it so chooses, then it must 
implement those restrictions for itself.  

libSSL does help (somewhat) by providing a function by which
the application may inquire if a cipher suite is a FIPS-approved
cipher suite, or not.  SSL_GetCipherSuiteInfo() returns a pointer
to a structure of information about a cipher suite.  
That SSLCipherSuiteInfo struct includes an isFIPS bit.  
see http://lxr.mozilla.org/security/source/security/nss/lib/ssl/sslt.h#139

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

In retrospect, I see that this RFE is really proposing that PSM itself have
a "FIPS mode".  Today, PSM offers GUI to enable or disable the FIPS mode in 
NSS's PKCS#11 softoken, but that's all it does.  This RFE proposes that PSM 
itself should have a FIPS mode that makes all the other application 
configuration changes needed to use that PKCS#11 module in conformance to 
the FIPS security policy for that module, which is seen at 
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp815.pdf

See also bug 339269.

Comment 4

[Bob Lord]

Does each application that uses NSS need to have its own FIPS mode?  I'm thinking of cases where there are many apps using NSS in the same user space at the same time.  In that case, there should be a master FIPS-mode control panel that strictly enforces that behavior.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Most applications have no need whatsoever for a FIPS mode.
There are applications for use only within government environments 
that have no need for a modal switch between FIPS/non-FIPS mode,
because they never operate in a non-FIPS mode.

Each application knows its own requirements.  NSS gives the application
complete control over what it wants to use.  

Having said that, I observe that in another related area, export control
policies, we give the application full control, the ability to disable any 
cipher suite (in SSL) in a way that cannot be overridden by user prefs. 
The level of granularity for that control is at the level of the individual
cipher suites.  This is done through the function SSL_CipherPolicySet.

see <http://mxr.mozilla.org/security/search?string=Policy&find=ssl/ssl.h>

But we also provide some functions that set pre-defined patterns of these
cipher policies.  NSS_SetFrancePolicy, NSS_SetExportPolicy, 
NSS_SetDomesticPolicy.  We could easily add another of those, 
NSS_SetFIPSPolicy. It's scope would be limited to SSL.

There are also a set of functions for setting policy for libSMIME.  See
<http://mxr.mozilla.org/security/search?string=Allow&case=on&find=mime&tree=security> 
There are no functions for predefined patterns in SMIME, but one or more
could be added pretty easily.

But that's about as far as it goes.  We can't automatically limit NSS to
using only FIPS validated PKCS#11 modules because there is no known way to 
programmatically determine if a PKCS#11 module is FIPS validated or not.
(Ask yourself how NSS would tell that softoken 3.11.4 is, but 3.12.1 is not.)

Further, FIPS rules are not always as black-and-white as they might seem.
MD5 is not a FIPS algorithm, but it's use in TLS 1.0 is permitted in FIPS 
compliant programs, and disabling all MD5 would disable all TLS.  So 
applying a blanket function to disable all non-FIPS algorithms entirely at 
a low level in FIPS mode would be counter productive, and is not required.

There is a program named "md5sum" commonly and widely used to compute 
checksums over files to ensure authenticity of downloads.  How would such 
a program work if a system wide "FIPS mode" disabled MD5?  Would it simply
not work at all?  

Further, applications that have UI (or configuration files) offering users
choices among ciphers probably need to be aware of "FIPS mode", and not 
offer users non-FIPS choices in FIPS mode.

Comment 6

[Bob Lord]

This page shows why this RFE is important:
http://support.mozilla.com/en-US/kb/Configuring+Firefox+for+FIPS+140-2?bl=n&s=fips

Most of those very tedious instructions can go away if clicking "Enable FIPS" turns off non-FIPS ciphersuites.