107619 - new TLS DHE_ ciphersuites are enabled by default

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Nelson Bolyard (seldom reads bugmail)]

To preserve backward compatibility with old programs, all new ciphersuites 
implemented in NSS releases since NSS 2.0 are supposed to be disabled by
default.  An application should have to explicitly enable any new cipher
suites that it desires.

Sadly, the new DHE ciphersuites are enabled by default.  
This may invalidate (or cause to fail) backward compatibility tests
because the DHE ciphersuites may be enabled when it is presumed that
they are not.

I'm not sure which NSS releases (if any) have been shipped with this code.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Attachment: patch to fix this bug.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Note that none of the new AES ciphersuites (including the DHE_.._AES ones) 
are enabled by default.  Only the older RC4 and 3DES DHE ciphersuites
are enabled by default.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

target milestone == 3.4 until we know what other releases may need 
to be fixed.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

I have checked in the fix on the trunk.  
I guess it should go into 3.3.x also. (?)

Comment 5

[Wan-Teh Chang]

NSS 3.3 is the first NSS release that has been shipped
with the new (client-side) DHE ciphersuites.  When iWS
6.0 SP1 upgraded to NSS 3.3, Julien reported that his
test client failed because the DHE ciphersuites were
enabled.  I didn't realize that that was wrong.

Comment 6

[Wan-Teh Chang]

I am confused about one issue.

So we know NSS 3.3 is not backward compatible with
NSS 3.2 because the new DHE ciphersuites are enabled
by default.

With this fix, NSS 3.4 will not be backward compatible
with NSS 3.3 but will be backward compatible with NSS
3.2.  In light of this, I am not sure if we should
check in this fix.

Comment 7

[Julien Pierre]

Ongoing, this begs the question of what the different security policies mean.
In NSS 3.3, the DHE suites were added to the domestic policy by default. Some
applications were not aware of their existence and so had them accidentally enabled.
I made a fix in web server 6.0 SP1 and the test client to enumerate all the
cipher suites and turn them off, so only the ones that are explicitly turned on
in the admin interface are actually used. Other applications may need a similar
fix, or they'll want to stick with NSS 3.2.x .

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

I think server products will not be able to NSS 3.3.0 - 3.3.1 
unless they are using the suggested algorithm of disabling
all ciphersuites (using the list provided by libssl, not a 
list compiled into the application), and then enable only the 
suites they actually want to use.  

The ssl tstclnt, strsclnt and selfserv programs all do this and their 
sources illustrate how to do it.  See, for example, function 
disableAllSSLCiphers()in any of those sources.

Finally, note that beginning with NSS 3.4, it will be possible for
an application to avoid having a compiled-in list of ssl cipher suites
alltogether while still offering a UI for managing them.  
See details in http://bugzilla.mozilla.org/show_bug.cgi?id=78959

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

I have checked in the change to disable the DHE ciphers by default 
on both the trunk and the NSS_3_3_BRANCH.  if/when we spin NSS 3.3.2
I believe it will contain this fix.