new TLS DHE_ ciphersuites are enabled by default

RESOLVED FIXED in 3.3.2

Status

NSS
Libraries
P1
major
RESOLVED FIXED
16 years ago
16 years ago

People

(Reporter: Nelson Bolyard (seldom reads bugmail), Assigned: Nelson Bolyard (seldom reads bugmail))

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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

16 years ago
Created attachment 55800 [details] [diff] [review]
patch to fix this bug.
(Assignee)

Comment 2

16 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

16 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

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

Comment 5

16 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

16 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

16 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

16 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

16 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
Last Resolved: 16 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.