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
This problem doesn't happen with the libnss3.so provided by upstream Firefox.
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.
(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?
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
(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
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.
Filed upstream bug https://github.com/libressl-portable/portable/issues/531 And bsd.network does look like it is using LibreSSL too.
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 ***