Closed
Bug 107619
Opened 23 years ago
Closed 23 years ago
new TLS DHE_ ciphersuites are enabled by default
Categories
(NSS :: Libraries, defect, P1)
Tracking
(Not tracked)
RESOLVED
FIXED
3.3.2
People
(Reporter: nelson, Assigned: nelson)
Details
Attachments
(1 file)
2.06 KB,
patch
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•23 years ago
|
||
Assignee | ||
Comment 2•23 years ago
|
||
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.
Assignee | ||
Comment 3•23 years ago
|
||
target milestone == 3.4 until we know what other releases may need to be fixed.
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → 3.4
Assignee | ||
Comment 4•23 years ago
|
||
I have checked in the fix on the trunk. I guess it should go into 3.3.x also. (?)
Comment 5•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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 .
Assignee | ||
Comment 8•23 years ago
|
||
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
Assignee | ||
Comment 9•23 years ago
|
||
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.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Target Milestone: 3.4 → 3.3.2
You need to log in
before you can comment on or make changes to this bug.
Description
•