Bug 1713416

Summary: SSL_ERROR_DECODE_ERROR_ALERT thrown in Firefox for some SSL domains
Product: [Fedora] Fedora Reporter: Lorne Greene <b37a>
Component: nssAssignee: Daiki Ueno <dueno>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 30CC: crypto-team, dueno, elio.maldonado.batiz, hkario, kdudka, kengert, tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-05-28 07:57:12 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:
Attachments:
Description Flags
ssltap results none

Description Lorne Greene 2019-05-23 15:22:07 UTC 
Created attachment 1572591 [details]
ssltap results

Description of problem:

When trying to open some websites (for example https://besirovic.com/) Firefox shows a SSL_ERROR_DECODE_ERROR_ALERT error and doesn't load the page.

This seems to be related to TLS 1.3 -- changing these settings for firefox in about:config make these domains work:

security.tls.version.max to "3" instead of "4" (4 is TLS 1.3)
security.tls.version.fallback-limit to "3" instead of "4"

This worked with nss-3.43.0-2.fc30.x86_64 but doesn't with nss-3.44.0-2.fc30.x86_64

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

    nss package info:
    Version      : 3.44.0
    Release      : 2.fc30
    Architecture : i686
    Size         : 3.5 M
    Source       : nss-3.44.0-2.fc30.src.rpm
    Repository   : @System

How reproducible:

Always. Managed to reproduce in a fresh install inside a VM with latest updates.

Steps to Reproduce:
1. upgrade all packages (firefox at version 67.0, release 3.fc30)
2. start firefox
3. go to https://besirovic.com/ or https://bsd.network/

Actual results:

See this error page:
An error occurred during a connection to bsd.network. Peer could not decode an SSL handshake message. Error code: SSL_ERROR_DECODE_ERROR_ALERT 

Expected results:
Page should load normally as it has a valid certificate.

Additional info:
I ran an ssltap instance and collected what it sees. It was started with:

ssltap -p 445 -sx besirovic.com:443

And then I loaded https://localhost:445/. The results are in the attached ssltap.txt file
Comment 1 Lorne Greene 2019-05-23 15:25:04 UTC 
This problem doesn't happen with the libnss3.so provided by upstream Firefox.
Comment 2 Tomas Mraz 2019-05-23 16:11:08 UTC 
Actually what's strange is that both gnutls and openssl which support TLS-1.3 as well can negotiate TLS-1.2 successfully with these servers. This really looks like some issue within nss handshake implementation.
Comment 3 Daiki Ueno 2019-05-27 14:13:49 UTC 
(In reply to Tomas Mraz from comment #2)
> Actually what's strange is that both gnutls and openssl which support
> TLS-1.3 as well can negotiate TLS-1.2 successfully with these servers. This
> really looks like some issue within nss handshake implementation.

GnuTLS client actually fails in the same way, if X25519 is disabled:
$ gnutls-cli --priority "NORMAL:-GROUP-X25519" -p 443 besirovic.com
Processed 154 CA certificate(s).
Resolving 'besirovic.com:443'...
Connecting to '45.77.67.94:443'...
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [50]: Decode error
zsh: exit 1     gnutls-cli --priority "NORMAL:-GROUP-X25519" -p 443 besirovic.com

Armin, do you happen to know which server implementation is used there?
Comment 4 Alicja Kario 2019-05-27 15:50:03 UTC 
yes, looks like a bug on the server side (which appears to be libressl)
when X22519 is excluded from the supported_groups extension but TLS 1.3 is offered, the negotiation fails
with X25519 present or TLS 1.3 not being offered, the negotiation succeeds
Comment 5 Alicja Kario 2019-05-27 15:52:49 UTC 
(In reply to Armin Beširović from comment #1)
> This problem doesn't happen with the libnss3.so provided by upstream Firefox.

this is because the upstream libnss3.so doesn't use the crypto-policies from Fedora-specific location, see bug 1713777 comment #2
Comment 6 Lorne Greene 2019-05-27 16:00:02 UTC 
Daiki, Hubert, not sure about bsd.network but besirovic.com is running OpenBSD 6.5, their httpd daemon with LibreSSL.
I'll check with upstream LibreSSL devs if this is a bug on their side.
Comment 7 Alicja Kario 2019-05-27 16:24:05 UTC 
Filed upstream bug https://github.com/libressl-portable/portable/issues/531

And bsd.network does look like it is using LibreSSL too.
Comment 8 Daiki Ueno 2019-05-28 07:57:12 UTC 
Thank you for the feedback.  I'm merging these bugs given they have the same cause.

*** This bug has been marked as a duplicate of bug 1713777 ***