Bug 1713416 - SSL_ERROR_DECODE_ERROR_ALERT thrown in Firefox for some SSL domains
Summary: SSL_ERROR_DECODE_ERROR_ALERT thrown in Firefox for some SSL domains
Keywords:
Status: CLOSED DUPLICATE of bug 1713777
Alias: None
Product: Fedora
Classification: Fedora
Component: nss
Version: 30
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Daiki Ueno
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-05-23 15:22 UTC by Armin Beširović
Modified: 2019-05-28 07:57 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-28 07:57:12 UTC


Attachments (Terms of Use)
ssltap results (10.77 KB, text/plain)
2019-05-23 15:22 UTC, Armin Beširović
no flags Details


Links
System ID Priority Status Summary Last Updated
Github libressl-portable portable issues 531 None None None 2019-05-27 16:24:04 UTC

Description Armin Beširović 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 Armin Beširović 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 Hubert 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 Hubert 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 Armin Beširović 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 Hubert 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 ***


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