1335919 – NSS: Disable TLS connections with less than 1023-bit DH parameters

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1335919 - NSS: Disable TLS connections with less than 1023-bit DH parameters

Summary: NSS: Disable TLS connections with less than 1023-bit DH parameters

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	nss
Sub Component:
Version:	6.9
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	Daiki Ueno
QA Contact:	Hubert Kario
Docs Contact:	Mirek Jahoda
URL:
Whiteboard:
Depends On:
Blocks:	1335911 1343211 1397979
TreeView+	depends on / blocked

Reported:	2016-05-13 14:26 UTC by Nikos Mavrogiannopoulos
Modified:	2020-12-11 12:12 UTC (History)
CC List:	10 users (show)
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.
Clone Of:	1335915
Environment:
Last Closed:	2017-03-21 10:26:42 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Priority	Status	Summary	Last Updated
Red Hat Bugzilla	1397979	medium	CLOSED	Policy file requires empty line at the end	2021-02-22 00:41:40 UTC
Red Hat Knowledge Base (Solution)	3194192	None	None	None	2017-09-25 09:57:50 UTC
Red Hat Product Errata	RHEA-2017:0671	normal	SHIPPED_LIVE	nspr and nss bug fix update	2017-03-21 12:35:29 UTC

Internal Links: 1397979

Description Nikos Mavrogiannopoulos 2016-05-13 14:26:26 UTC

RHEL includes several cryptographic components who's security doesn't remain constant over time. Algorithms such as (cryptographic) hashing and encryption typically have a lifetime after which they are considered either too risky to use or plain insecure. That would mean we need to phase out such algorithms from the default settings, or completely disable if they could cause irreparable issue. 

This bug is about disabling any TLS connections which utilize less than 1024-bit Diffie-Hellman parameters, while at the same hand providing a configuration method for these parameters to be allowed when needed.

For future extensibility in RHEL-7 it is recommended for any introduced configuration method to be re-usable for future algorithm or parameter deprecation (e.g., SHA1 or less than 1024-bit RSA/DH parameters), and ideally part of upstream.

Comment 3 Kai Engert (:kaie) (inactive account) 2016-09-30 09:34:03 UTC

Nikos, we must clarify, what should be done for DH parameters of EXACTLY 1024 bit?

Disable, or keep enabled?

Comment 4 Kai Engert (:kaie) (inactive account) 2016-09-30 09:39:31 UTC

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?

Comment 5 Kai Engert (:kaie) (inactive account) 2016-09-30 09:42:48 UTC

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 ?

Comment 9 Hubert Kario 2016-09-30 10:53:46 UTC

(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

Comment 10 Kai Engert (:kaie) (inactive account) 2016-09-30 11:30:37 UTC

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

Comment 11 Hubert Kario 2016-09-30 12:24:43 UTC

(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

Comment 14 Hubert Kario 2016-11-23 18:37:31 UTC

Issue with NSS requiring an empty line at the end of policy file before it is recognised is tracked in bug 1397979.

Comment 19 errata-xmlrpc 2017-03-21 10:26:42 UTC

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

Comment 20 daniel 2017-09-25 09:57:51 UTC

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

Comment 21 Nikos Mavrogiannopoulos 2017-09-25 11:18:37 UTC

It is on the deprecated functionality section:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html

https://access.redhat.com/blogs/766093/posts/3050871

Note You need to log in before you can comment on or make changes to this bug.