DescriptionKai Engert (:kaie) (inactive account)
2017-05-24 16:27:21 UTC
+++ This bug was initially created as a clone of Bug #1423401 +++
Description of problem:
I'm working on TLS 1.3 related patches for mod_nss. For testing I created a COPR with TLS 1.3 enabled NSS 3.28.1, patched mod_nss and patched python-nss https://copr.fedorainfracloud.org/coprs/cheimes/nss/ . I noticed that neither python-nss nor Firefox nightly are able to connect to mod_nss-powered Apache HTTPD when mod_nss is configured for TLSv1.3 only and the mod_nss option NSSRequireSafeNegotiation is enabled. The option sets SSL_REQUIRE_SAFE_NEGOTIATION.
With NSSRequireSafeNegotiation on:
python-nss fails with: (SSL_ERROR_NO_CYPHER_OVERLAP) Cannot communicate securely with peer: no common encryption algorithm(s).
Firefox nightly fails with: SSL_ERROR_NO_CYPHER_OVERLAP
Apache HTTP error_log: SSL Library Error: -12175 Safe negotiation required but not provided by client
Wireshark shows a TLS 1.0 handshake (0x301) with renegotiation_info extension (0xff01) and a couple of unknown extensions (40 key share, 43 supported version, 45 psk kx).
With NSSRequireSafeNegotiation off:
python-nss: successful TLS 1.3 connection with TLS_AES_128_GCM_SHA256
Firefox nightly: successful TLS 1.3 connection with TLS_AES_128_GCM_SHA256
Version-Release number of selected component (if applicable):
NSS 3.28.1 with TLS 1.3 enabled
mod_nss 1.0.14+ with https://pagure.io/fork/cheimes/mod_nss/branch/tls13
How reproducible:
Always SSL_REQUIRE_SAFE_NEGOTIATION on
Steps to Reproduce:
1. Install NSS and mod_nss from my copr
2. change /etc/httpd/conf.d/nss.conf and supply a certificate for mod_nss.
NSSRenegotiation on
NSSRequireSafeNegotiation on
NSSCipherSuite +aes_128_gcm_sha_256,+chacha20_poly1305_sha_256
NSSProtocol TLSv1.3
3. test with Firefox nightly
Actual results:
SSL_ERROR_NO_CYPHER_OVERLAP
Expected results:
TLS 1.3 connection
Additional info:
--- Additional comment from Kai Engert (:kaie) on 2017-02-22 14:34:03 EST ---
If mod_nss independently configures allowed cipher suites, have you changed it to allow the new TLS 1.3 ciphersuites?
--- Additional comment from Kai Engert (:kaie) on 2017-02-22 14:36:54 EST ---
Could you run "ssltap -s" on your system, connect firefox through ssltap to your server, and attach the output from ssltap?
--- Additional comment from Rob Crittenden on 2017-02-22 14:49:59 EST ---
(In reply to Kai Engert (:kaie) from comment #1)
> If mod_nss independently configures allowed cipher suites, have you changed
> it to allow the new TLS 1.3 ciphersuites?
Yes, see https://pagure.io/mod_nss/pull-request/35
--- Additional comment from Christian Heimes on 2017-02-22 14:55:07 EST ---
Yes, see step 2 of reproducer.
With "NSSRequireSafeNegotiation off", I'm able to successfully connect to mod_nss over TLS1.3. With "NSSRequireSafeNegotiation on" I get SSL_ERROR_NO_CYPHER_OVERLAP.
--- Additional comment from Christian Heimes on 2017-02-22 14:55:50 EST ---
memo to me: provide ssltap data for Kai.
--- Additional comment from Hubert Kario on 2017-02-22 20:14:19 EST ---
> Wireshark shows a TLS 1.0 handshake (0x301) with renegotiation_info extension (0xff01) and a couple of unknown extensions (40 key share, 43 supported version, 45 psk kx).
I'm assuming you're talking about version in record layer, not the version in the Client Hello message?
--- Additional comment from Hubert Kario on 2017-02-23 07:19:49 EST ---
Kai, I can't reproduce it using selfserv, the necessary option is missing from selfserv: https://bugzilla.mozilla.org/show_bug.cgi?id=1342019
--- Additional comment from Rob Crittenden on 2017-05-01 16:59:39 EDT ---
I've also reproduced using Kai's copr build from https://copr.fedorainfracloud.org/coprs/kengert/nss-with-tls-1.3/ and Christian's mod_nss build from https://copr.fedorainfracloud.org/coprs/cheimes/nss/
Comment 2Kai Engert (:kaie) (inactive account)
2017-07-11 13:11:55 UTC
I think we don't need the selfserv enhancement, I've closed the upstream bug as wontfix.
I think what we need is:
"the server shouldn't fail, but use a backwards compatible behavior,
that ignores the configuration?"
I've filed an upstream bug to request and solve that:
https://bugzilla.mozilla.org/show_bug.cgi?id=1375837
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://access.redhat.com/errata/RHSA-2019:2237