Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1277611 - nss 3.19-1 is unable to connect to SSL servers using a public key starting with more than two leading 0 bits
Summary: nss 3.19-1 is unable to connect to SSL servers using a public key starting wi...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: nss
Version: 7.1
Hardware: All
OS: All
medium
high
Target Milestone: rc
: ---
Assignee: nss-nspr-maint
QA Contact: Hubert Kario
URL:
Whiteboard:
Depends On:
Blocks: 1203710 1295396 1296594 1313485
TreeView+ depends on / blocked
 
Reported: 2015-11-03 16:20 UTC by Felix Dewaleyne
Modified: 2019-12-16 05:04 UTC (History)
9 users (show)

Fixed In Version: nss-3.21.0-5.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-04 03:56:11 UTC
Target Upstream Version:


Attachments (Terms of Use)
Calculate DSA and DH key sizes based on prime, not public key (896 bytes, patch)
2016-02-16 18:13 UTC, Elio Maldonado Batiz
rrelyea: review+
Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Mozilla Foundation 1211403 0 None None None 2016-01-22 16:13:17 UTC
Red Hat Product Errata RHBA-2016:2335 0 normal SHIPPED_LIVE nss bug fix update 2016-11-03 13:45:11 UTC

Description Felix Dewaleyne 2015-11-03 16:20:50 UTC
Description of problem:
When connecting to a server using a public key starting with more than 2 leading bits set to 0, with NSS 3.19-1 this results in a security warning. This wasn't the case with NSS 3.18


Version-Release number of selected component (if applicable):
nss 3.19-1

How reproducible:
all the time 

Steps to Reproduce:
1. get server using a certificate affected
2. issue a curl connection to it


Actual results:
Client sends a TLS alert reporting a "insufficient_security"


Expected results:
normal connection, as of nss 3.18

Additional info:
see https://bugzilla.mozilla.org/show_bug.cgi?id=1211403

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.19.1_release_notes shows that DSS/DSA with 1024 should work. it also states that "NSS reports the bit length of keys more accurately.  Thus, the SECKEY_PublicKeyStrength and SECKEY_PublicKeyStrengthInBits functions could report smaller values for values that have leading zero values. This affects the key strength values that are reported by SSL_GetChannelInfo. ".  

customer info :
You need a server presented such a public key:
- We used 4 Tomcat servers
- use openssl to check server's public key contents
echo | openssl s_client -connect myserver:myport 2>/dev/null | openssl x509 -text -noout
- check the first bytes of the public key showed
- one of our 4 servers had a public starting with 0x11

Comment 6 Elio Maldonado Batiz 2016-01-18 15:19:08 UTC
Backport to 3.21, given that are likely to rebase, the upstream fix at 
https://bug1211403.bmoattachments.org/attachment.cgi?id=8695104 which was for https://bugzilla.mozilla.org/show_bug.cgi?id=1211403 and is targeted for the upstream nss-3.22 release. It should should be included.

Comment 7 Nikos Mavrogiannopoulos 2016-01-22 16:12:50 UTC
This issue can be solved using a rebase to nss-3.22.

Comment 11 Elio Maldonado Batiz 2016-02-16 18:13:34 UTC
Created attachment 1127664 [details]
Calculate DSA and DH key sizes based on prime, not public key

Backport to nss-3.21 of https://hg.mozilla.org/projects/nss/rev/075e80f679d1

Comment 12 Bob Relyea 2016-02-17 01:14:33 UTC
Comment on attachment 1127664 [details]
Calculate DSA and DH key sizes based on prime, not public key

r+ rrelyea

This is also more correct. A small public key is just as secure as any other public key as long as the private key is long enough (g is 2 and the public key is 8, then it's pretty obvious the private key is 3, which is too short).

Comment 20 errata-xmlrpc 2016-11-04 03:56:11 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/RHBA-2016-2335.html


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