Bug 1423401

Summary: TLS 1.3 handshake fails with SSL_REQUIRE_SAFE_NEGOTIATION on
Product: [Fedora] Fedora Reporter: Christian Heimes <cheimes>
Component: nssAssignee: nss-nspr-maint <nss-nspr-maint>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 25CC: cheimes, dueno, emaldona, hkario, kdudka, kengert, rcritten, sardella
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1455288 (view as bug list) Environment:
Last Closed: 2017-10-18 12:52:46 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: 1455288, 1457787    

Description Christian Heimes 2017-02-17 09:13:55 UTC
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:

Comment 1 Kai Engert (:kaie) (inactive account) 2017-02-22 19:34:03 UTC
If mod_nss independently configures allowed cipher suites, have you changed it to allow the new TLS 1.3 ciphersuites?

Comment 2 Kai Engert (:kaie) (inactive account) 2017-02-22 19:36:54 UTC
Could you run "ssltap -s" on your system, connect firefox through ssltap to your server, and attach the output from ssltap?

Comment 3 Rob Crittenden 2017-02-22 19:49:59 UTC
(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

Comment 4 Christian Heimes 2017-02-22 19:55:07 UTC
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.

Comment 5 Christian Heimes 2017-02-22 19:55:50 UTC
memo to me: provide ssltap data for Kai.

Comment 6 Alicja Kario 2017-02-23 01:14:19 UTC
> 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?

Comment 7 Alicja Kario 2017-02-23 12:19:49 UTC
Kai, I can't reproduce it using selfserv, the necessary option is missing from selfserv: https://bugzilla.mozilla.org/show_bug.cgi?id=1342019

Comment 8 Rob Crittenden 2017-05-01 20:59:39 UTC
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 9 Kai Engert (:kaie) (inactive account) 2017-06-23 13:30:07 UTC
My understanding is that renegotiation is forbidden with TLS 1.3
https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.txt

I don't know if the enabling of TLS 1.3 support on a server requires that the server side disables any support for renegotiation, or if the NSS server code should implement a compatibility behavior.

I've reported this upstream at:
  https://bugzilla.mozilla.org/show_bug.cgi?id=1375837

(In the future, I'd like to encourage you to report such bugs directly to the upstream, because that's where the people are that actually implement the TLS 1.3 code. You didn't get anything by reporting this as a Fedora package bug, besides a 4 month delay until I was able to be the middleman here and forward.)

Comment 10 Christian Heimes 2017-10-18 12:36:09 UTC
Thanks for proxying my request. Next time I'll directly open a request in upstream.

According to the upstream tracker, the issue has been fixed in NSS 3.33. I don't have time to verify the fix with mod_nss. IMO it's ok to close this bug. After all TLS 1.3 is still in draft mode and mod_nss doesn't support TLS 1.3 yet.