NSS

Disable TLS below 1.2 by default

Bug #1856428 reported by Dimitri John Ledkov
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
NSS
Fix Released
Unknown
gnutls28 (Ubuntu)
Fix Released
Undecided
Unassigned
nss (Debian)
Confirmed
Unknown
nss (Ubuntu)
Fix Released
Undecided
Unassigned
openssl (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Disable TLS 1.0, TLS1.1, DTLS1.0

As part of focal commitment, we shall disable obsolete protocols by default.

Users can override this behaviour with a config file.

Related branches

CVE References

summary: - Raise minimum key requirements to 2k and disable TLS 1.0 and 1.1
+ Disable TLS1.0, TLS 1.1, DTLS1.0
description: updated
tags: added: id-5db1c4c64e98bd59adc18616
summary: - Disable TLS1.0, TLS 1.1, DTLS1.0
+ Disable TLS1.0, TLS 1.1
Changed in openssl (Ubuntu):
status: New → In Progress
Changed in openssl (Ubuntu):
status: In Progress → Fix Committed
Changed in gnutls28 (Ubuntu):
status: New → In Progress
Changed in nss (Ubuntu):
status: New → Triaged
Changed in gnutls28 (Ubuntu):
status: In Progress → Fix Committed
Changed in nss (Ubuntu):
status: Triaged → Fix Committed
summary: - Disable TLS1.0, TLS 1.1
+ Disable TLS below 1.2 by default
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nss - 2:3.48-1ubuntu1

---------------
nss (2:3.48-1ubuntu1) focal; urgency=low

  * Merge from Debian unstable. Remaining changes:
    - d/libnss3.links: make freebl3 available as library (LP #1744328)
    - d/control: add dh-exec to Build-Depends
    - d/rules: make mkdir tolerate debian/tmp existing (due to dh-exec)
    - Disable reading fips_enabled flag in FIPS mode. libnss is
      not a FIPS certified library. (LP #1837734)
  * Set TLSv1.2 as minimum TLS version. LP: #1856428

nss (2:3.48-1) unstable; urgency=medium

  * New upstream release. Closes: #947131.
  * debian/control: Bump nspr build dependency to 4.24.
  * nss/lib/freebl/Makefile: Disable hardware AES on ARM softfloat to fix
    FTBFS on armel. Closes: #947246.

nss (2:3.47.1-1) unstable; urgency=medium

  * New upstream release.
    - Fixes CVE-2019-11745.

 -- Ubuntu Merge-o-Matic <email address hidden> Sun, 29 Dec 2019 03:43:36 +0000

Changed in nss (Ubuntu):
status: Fix Committed → Fix Released
Changed in gnutls28 (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
James Henstridge (jamesh) wrote :

For anyone who finds this bug, and wonders about the "Users can override this behaviour with a config file" part, here's what I did to get an OpenSSL-using application to talk to an old server that only supported TLSv1 (in my case, an old Mumble server):

1. create an "openssl.cnf" file somewhere with the following contents:

    openssl_conf = openssl_init

    [openssl_init]
    ssl_conf = ssl_sect

    [ssl_sect]
    system_default = system_default_sect

    [system_default_sect]
    CipherString = DEFAULT@SECLEVEL=1

2. set the OPENSSL_CONF environment variable to this file's path when running the application.

I wouldn't recommend making the change to the global /etc/ssl/openssl.cnf, or setting $OPENSSL_CONF for situations where it isn't needed, since this does reduce the default security.

Changed in openssl (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

Ubuntu is patching it to change the default range of TLS versions. https://bugs.launchpad.net/bugs/1856428

Should this be done to NSS itself?

Revision history for this message
In , Mt-l (mt-l) wrote :

I would be supportive of that change (see also [RFC8996](https://www.rfc-editor.org/rfc/rfc8996.html)), but we generally try to coordinate with RedHat on this sort of thing. We don't have the same sorts of constraints. Firefox doesn't use defaults, we explicitly set these.

So...Bob, I'm supportive of this, what about you?

I assume that you need some warning (this current release is due to go out Friday, so that is almost certainly "no"). How long would you need to make the necessary arrangements for RHEL backports and so forth? Would NSS 3.70 be unreasonable?

Revision history for this message
In , Rrelyea (rrelyea) wrote :

3.69 would be fine. We just rebased for ESV, so we won't be picking up a rhel version of nss anytime soon.

We now set those defaults by policy anyway, so we probably only need backports for rhel-7.x (which we already have because rhel-7 still has ssl3 on by default).

RHEL-8 policy is already tls 1.2 min in our default policy (which actually surprises me, I thought it was tls 1.0). So I'm sure we are tls 1.2 min in fedora, where sha1 is also turned off by policy for signatures and ssl.

Revision history for this message
In , Mt-l (mt-l) wrote :

Created attachment 9233646
Bug 1722613 - Disable DTLS 1.0 and 1.1 by default, r=rrelyea

Revision history for this message
In , Mt-l (mt-l) wrote :

Well then. We should catch up then.

I've put up a patch for just that. I've included DTLS 1.0 as well, following IETF advice.

I'm running all.sh locally and then there is also https://treeherder.mozilla.org/#/jobs?repo=nss-try&revision=876925f6a0da Assuming that goes well, I'll make sure that this is in the Beta release planned for tomorrow.

Revision history for this message
In , Mt-l (mt-l) wrote :
Changed in nss:
status: Unknown → Fix Released
Changed in nss (Debian):
status: Unknown → Confirmed
Mathew Hodson (mhodson)
no longer affects: golang-1.13 (Ubuntu)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.