Bug 1335919
Summary: | NSS: Disable TLS connections with less than 1023-bit DH parameters | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Nikos Mavrogiannopoulos <nmavrogi> |
Component: | nss | Assignee: | Daiki Ueno <dueno> |
Status: | CLOSED ERRATA | QA Contact: | Hubert Kario <hkario> |
Severity: | unspecified | Docs Contact: | Mirek Jahoda <mjahoda> |
Priority: | unspecified | ||
Version: | 6.9 | CC: | dmoessne, dueno, hkario, kengert, mjahoda, nss-nspr-maint, qe-baseos-security, rrelyea, szidek, tmraz |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | nss-3.27.1-1.el6 | Doc Type: | Deprecated Functionality |
Doc Text: |
*NSS* clients using *TLS* with less than 1024-bit DH are not allowed
This change prevents *NSS* clients from connecting to servers with Diffie-Hellman (DH) parameters less than 1024 bits. This ensures that allowed clients using *NSS* are not vulnerable to attacks such as the LOGJAM attack.
A system administrator can enable shorter DH parameter support by modifying the `/etc/pki/nss-legacy/nss-rhel6.config` policy configuration file to:
library=
name=Policy
NSS=flags=policyOnly,moduleDB
config="allow=DH-MIN=767:DSA-MIN=767:RSA-MIN=767"
Note that an empty line is required at the end of the file.
|
Story Points: | --- |
Clone Of: | 1335915 | Environment: | |
Last Closed: | 2017-03-21 10:26:42 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1335911, 1343211, 1397979 |
Description
Nikos Mavrogiannopoulos
2016-05-13 14:26:26 UTC
Nikos, we must clarify, what should be done for DH parameters of EXACTLY 1024 bit? Disable, or keep enabled? Let's assume, that Nikos want us to disable the DH params with exactly 1024 bit. Hubert, you said in the past, we require 1024 bit for Java compatibility. And we had implemented API SSL_EnableWeakDHEPrimeGroup to provide support for 1024 bit compatibility. Does that mean, we should patch SSL_EnableWeakDHEPrimeGroup to NOT enable the 1024 bit group? Open question, should it return a failure, or should it be a no-operation? Daiki pointed me to a patch in RHEL 6.x, which shows, that upstream requires a minimum DH size of 1023 bits. We had decreased that limit in previous RHEL 6.x to 768 bits. Should we use the same as upstream, and increase the limit to 1023 ? (In reply to Kai Engert (:kaie) from comment #4) > Let's assume, that Nikos want us to disable the DH params with exactly 1024 > bit. > > Hubert, you said in the past, we require 1024 bit for Java compatibility. > > And we had implemented API SSL_EnableWeakDHEPrimeGroup to provide support > for 1024 bit compatibility. > > Does that mean, we should patch SSL_EnableWeakDHEPrimeGroup to NOT enable > the 1024 bit group? > > Open question, should it return a failure, or should it be a no-operation? If the system policy is to disable 1024 bit DH and application tries to enable 1024 bit DH, in my opinion the call should fail. Similarly to how trying to generate 256 bit RSA key now will fail. Rationale being: 1. the application should not use this API by default, it should require explicit setting by user (so user should be able to disable use of that api in application) 2. even in the case the application is broken and forces that setting on user, the user can change the system policy to legacy where the call should succeed I believe the summary of this bug should be changed to: "Disable ... with less than 1023-bit DH" If this is what we do, then we'll continue to support the 1024-bit DH, and the current APIs don't need to be changed, because we'd still allow the application to allow the 1024 bit groups. (I hope I'm not confusing anything between DH and DHE?) Possibly, the only change necessary here is to remove this patch? http://pkgs.devel.redhat.com/cgit/rpms/nss/tree/ssl-server-min-key-sizes.patch?h=rhel-6.9 (In reply to Kai Engert (:kaie) from comment #10) > I believe the summary of this bug should be changed to: > > "Disable ... with less than 1023-bit DH" > > If this is what we do, then we'll continue to support the 1024-bit DH, and > the current APIs don't need to be changed, because we'd still allow the > application to allow the 1024 bit groups. yes, we want to continue to support 1024 bit while dropping support for 1023 bit at the same time is an arbitrary threshold, I haven't see any servers that advertise 1023 bit DH parameters (unlike RSA keys) > (I hope I'm not confusing anything between DH and DHE?) while there is a difference between (static) DH and DHE, NSS only supports the latter, and in that case it's all unambitious > Possibly, the only change necessary here is to remove this patch? > > http://pkgs.devel.redhat.com/cgit/rpms/nss/tree/ssl-server-min-key-sizes. > patch?h=rhel-6.9 no, it's not sufficient. The change in question must be reversible by changing system configuration, yes the default should match the upstream behaviour, but user needs to be able to set the NSS behaviour to the way NSS behaved in the past Issue with NSS requiring an empty line at the end of policy file before it is recognised is tracked in bug 1397979. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2017-0671.html cannot find this in release docs, could someone please point me to where this is stated in the official docs? Other wise I am inclined to reopen this bug until docs text is included in release notes |