106604 - Disable all non-FIPS ciphersuites while in FIPS mode

Status: NEW

(Core :: Security: PSM, defect, P5)

Description

[Kai Engert [:KaiE:]]

see bug 106526

During FIPS mode, all SSL2 ciphers should be disabled.

I suggest that disabling the ciphers is independent of what a user configures in
the UI (allowed ciphers).

This way, when a user leaves FIPS mode, the previously selected selection SSL2
ciphers will be as before.

I suggest that while in FIPS mode, the UI for selecting the prefered ciphers
should gray out ciphers currently not allowed.

Comment 1

[Kai Engert [:KaiE:]]

P1, PSM 2.2

Comment 2

[Kai Engert [:KaiE:]]

But, is it correct, that PSM must take action to disable SSL2 in NSS when FIPS
mode is enabled?

If you agree, I will add code that does
  SSL_OptionSetDefault(SSL_ENABLE_SSL2, PR_FALSE);when FIPS is disabled, and 
  SSL_OptionSetDefault(SSL_ENABLE_SSL2, user_preference);when FIPS is enabled.

Comment 3

[Stephane Saux]

FIPS mode and SSL2 are mutually exclusive. Thus, when somebody tries to connect
to a site that only does ssl2 (or other pki functions), then there should be
some error. The best solution would tell the user that in FIPS mode ssl2 is
disabled. Disabling SSL2 internally, even though the preferences show that it's
enabled will result in a confusing message to the user.  He will be told that he
can't connect because ssl2 is disabled, but the preferences will show otherwise.

We should try and see whether we can make the right fix (e.g., in NSS act as if
ssl2 is disabled, but at the application level, give better feedback to the user
as to the true cause of the SSL failure.

Comment 4

[John Unruh]

nsbeta1

Comment 5

[Stephane Saux]

nsbeta1+

Comment 6

[Kai Engert [:KaiE:]]

Should we relnote this?

Comment 7

[Julien Pierre]

Right now, libssl will return an error of "no cipher overlap" if you try to 
connect to an SSL2-only site, but SSL2 is disabled on the socket. This is not a 
specific enough error for the application to be able to tell that there is also 
no protocol version overlap.
What we would need is a way to get more information about the error, eg. 
retrieve a list of the ciphers & protocols supported by the server side, and 
then PSM could check that against its own list and make a smart determination of 
the correct error message to display to the user.
Nelson, do you think this is something that can and should be implemented ?

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

If the client has SSL2 disabled, but has not disabled sslv2 compatible 
client hellos, then the client will send an sslv2-formatted client
hello, bearing version 3.0 or 3.1 to the server, and the server (being
an SSL2 only server) will respond with an SSL2 server hello message.  
When the client receives and processes that message, in 
ssl2_HandleServerHelloMessage the code will detect that ssl2 is locally
disabled and return SSL_ERROR_SSL2_DISABLED.  

Is that not the behavior you're seeing?

The application should report that the server is an SSL2 only server.
That is what Communicator 4.x does.  

Comment 9

[Julien Pierre]

Nelson, I was unaware of that SSL option. The tests I had conduced only disabled 
SSL2 ciphers but not the protocol itself on the client side, so I never got the 
SSL2 disabled error.
If FIPS is disabled, there is no problem, PSM displays the "SSL2 is disabled" 
error.

However with it enabled, nothing happens. The connection begins, then just 
aborts. There is no error displayed. I'm not certain how to use FIPS though so I 
could have done something wrong - I just typed enter for the password to the 
FIPS token. Still this is confusing.

Comment 10

[R. Pao]

http://bugzilla.mozilla.org/show_bug.cgi?id=184598
is apparently related.

Comment 11

[Kai Engert [:KaiE:]]

changing obsolete psm* target to --- (unspecified)

Comment 12

[Bob Lord]

SSL2 is off by default.  OK to close this bug report now?

Comment 13

[Bob Lord]

This one also looks like a dup/subset of Bug 339267.

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

Yes, SSL2 is off by default, but is that good enough for FIPS?
If the user has re-enabled SSL2 and then turns on FIPS mode, he'll 
still have SSL2 enabled.  Is that really good enough?  

Newer (higher numbered) bugs should preferably be marked as dup's of older 
(lower numbered) ones, and not vice-versa, IMO.

Comment 16

[Bob Lord]

Bug 339267 has a great deal more information. Please read that bug report also.

Changing title to better reflect the greater need to make going into FIPS mode disable non-FIPS ciphersuites.

Comment 17

[lamalbrut]

Hello. Enabled FIPS 140-2 mode for NSS Internal PKCS #11 module – in 'about:preferences#privacy' page, Security devices – has indeed no automatic effect on states of cipher suites supported by the Firefox 94 client – in page 'about:config' – which are:

security.ssl3.deprecated.rsa_des_ede3_sha true
security.ssl3.dhe_rsa_aes_128_sha false
security.ssl3.dhe_rsa_aes_256_sha false
security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256 true
security.ssl3.ecdhe_ecdsa_aes_128_sha true
security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384 true
security.ssl3.ecdhe_ecdsa_aes_256_sha true
security.ssl3.ecdhe_ecdsa_chacha20_poly1305_sha256 true
security.ssl3.ecdhe_rsa_aes_128_gcm_sha256 true
security.ssl3.ecdhe_rsa_aes_128_sha true
security.ssl3.ecdhe_rsa_aes_256_gcm_sha384 true
security.ssl3.ecdhe_rsa_aes_256_sha true
security.ssl3.ecdhe_rsa_chacha20_poly1305_sha256 true
security.ssl3.rsa_aes_128_gcm_sha256 true –
security.ssl3.rsa_aes_128_sha true
security.ssl3.rsa_aes_256_gcm_sha384 true
security.ssl3.rsa_aes_256_sha true

The knowledge of a source communicating the official list of cipher suites observing the 140-2 specification would at last enable to update the obsolete information that is in the document at https://support.mozilla.org/en-US/kb/Configuring%20Firefox%20for%20FIPS%20140-2.