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.
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.
target milestone == 3.4 until we know what other releases may need to be fixed.
I have checked in the fix on the trunk. I guess it should go into 3.3.x also. (?)
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.
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.
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 .
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
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.