Bug#989839: Bug#989843: thunderbird: Problem loading page: NS_ERROR_NET_INADEQUATE_SECURITY

2021-06-17 Thread Jürgen Kübler

Installing libnss3_3.67-1_amd64.deb from sid solved the issue for me.

Cheers,
Jürgen

On Wed, 16 Jun 2021 14:17:45 -0600 Kevin Locke  
wrote:

> On Wed, 2021-06-16 at 11:55 -0600, Kevin Locke wrote:
> > Setting a breakpoint on SSL_GetChannelInfo revealed that it is 
called by

> > PreliminaryHandshakeDone with len = 128 by 78.10.0 and len = 136 by
> > 78.11.0, which causes `len > sizeof inf` to fail and return SECFailure
> > (because `sizeof inf` is 128).
> >
> > It appears that SSLChannelInfo added pskType in NSS 3.54, echAccepted
> > in NSS 3.60, and isFIPS in NSS 3.66. Perhaps there is a version
> > mismatch?
>
> After a bit more testing, I realized thunderbird 1:78.10.2-1 was built
> with libnss3-dev 2:3.63-1 and thunderbird 1:78.11.0-1 was built with
> libnss3-dev 2:3.66-1. I am only able to reproduce the issue with
> libnss3 2:3.61-1, not libnss3 2:3.67-1 from unstable.
>
> Cheers,
> Kevin
>
> 
https://buildd.debian.org/status/fetch.php?pkg=thunderbird=amd64=1%3A78.11.0-1=1622744401=0
> 
https://buildd.debian.org/status/fetch.php?pkg=thunderbird=amd64=1%3A78.10.2-1=1621535757=0

>
>

--

*Dr Jürgen Kübler*
Europabadstr. 8, 35041 Marburg, Germany
Tel: +49-6421-9686597
Mobile: +49-170-9352511



Bug#989839: Bug#989843: thunderbird: Problem loading page: NS_ERROR_NET_INADEQUATE_SECURITY

2021-06-16 Thread Kevin Locke
On Wed, 2021-06-16 at 11:55 -0600, Kevin Locke wrote:
> Setting a breakpoint on SSL_GetChannelInfo revealed that it is called by
> PreliminaryHandshakeDone with len = 128 by 78.10.0 and len = 136 by
> 78.11.0, which causes `len > sizeof inf` to fail and return SECFailure
> (because `sizeof inf` is 128).
> 
> It appears that SSLChannelInfo added pskType in NSS 3.54, echAccepted
> in NSS 3.60, and isFIPS in NSS 3.66.  Perhaps there is a version
> mismatch?

After a bit more testing, I realized thunderbird 1:78.10.2-1 was built
with libnss3-dev 2:3.63-1 and thunderbird 1:78.11.0-1 was built with
libnss3-dev 2:3.66-1.  I am only able to reproduce the issue with
libnss3 2:3.61-1, not libnss3 2:3.67-1 from unstable.

Cheers,
Kevin

https://buildd.debian.org/status/fetch.php?pkg=thunderbird=amd64=1%3A78.11.0-1=1622744401=0
https://buildd.debian.org/status/fetch.php?pkg=thunderbird=amd64=1%3A78.10.2-1=1621535757=0



Bug#989839: Bug#989843: thunderbird: Problem loading page: NS_ERROR_NET_INADEQUATE_SECURITY

2021-06-16 Thread Kevin Locke
Comparing the log.moz_log from running thunderbird with MOZ_LOG=nsHttp:3
and MOZ_LOG_FILE=log in the environment shows
Http2Session::ConfirmTLSProfile gets version=304 from
ssl->GetSSLVersionUsed() in 78.10.0 and version=
(nsISSLSocketControl::SSL_VERSION_UNKNOWN) in 78.11.0, which causes
Http2Session::ConfirmTLSProfile "FAILED due to lack of TLS1.2" and
INADEQUATE_SECURITY[1]:

I/nsHttp Http2Session::ConfirmTLSProfile 0x7f78dbdb7000 version=
I/nsHttp Http2Session::ConfirmTLSProfile 0x7f78dbdb7000 FAILED due to lack 
of TLS1.2
I/nsHttp Http2Session::SessionError 0x7f78dbdb7000 reason=0xc 
mPeerGoAwayReason=0x1f
I/nsHttp Http2Session::ReadSegments 0x7f78dbdb7000 returning 
INADEQUATE_SECURITY 804b0052

Setting a breakpoint on SSL_GetChannelInfo revealed that it is called by
PreliminaryHandshakeDone with len = 128 by 78.10.0 and len = 136 by
78.11.0, which causes `len > sizeof inf` to fail and return SECFailure
(because `sizeof inf` is 128).

It appears that SSLChannelInfo added pskType in NSS 3.54, echAccepted
in NSS 3.60, and isFIPS in NSS 3.66.  Perhaps there is a version
mismatch?

Best,
Kevin

[ConfirmTLSProfile]: 
https://hg.mozilla.org/releases/mozilla-esr78/file/FIREFOX_78_11_0esr_RELEASE/netwerk/protocol/http/Http2Session.cpp#l4194
[PreliminaryHandshakeDone]: 
https://hg.mozilla.org/releases/mozilla-esr78/file/FIREFOX_78_11_0esr_RELEASE/security/manager/ssl/nsNSSCallbacks.cpp#l700
[SSL_GetChannelInfo]: 
https://hg.mozilla.org/releases/mozilla-esr78/file/FIREFOX_78_11_0esr_RELEASE/security/nss/lib/ssl/sslinfo.c#l13
[SSLChannelInfo FF78]: 
https://hg.mozilla.org/releases/mozilla-esr78/file/FIREFOX_78_11_0esr_RELEASE/security/nss/lib/ssl/sslt.h#l293
[SSLChannelInfo tip]: 
https://hg.mozilla.org/mozilla-central/file/tip/security/nss/lib/ssl/sslt.h#l299



Bug#989839: Bug#989843: thunderbird: Problem loading page: NS_ERROR_NET_INADEQUATE_SECURITY

2021-06-15 Thread Carsten Schoenert
Control: tags 989839 severity important
Control: tags 989843 severity important
Control: merge 989843 989839
thanks

Hello *,

decreasing the severity as Thunderbird isn't *completely* unusable.

Am 14.06.21 um 19:31 schrieb Todor Tsankov:
> Dear Maintainer,
> 
> Since the update to 78.11.0 Thunderbird cannot load various webpages. To
> reproduce the error, try to do a search in the Add-ons Manager (type
> something in the search box and press Enter).
> 
> The error message is
> 
> "The website tried to negotiate an inadequate level of security.
> ...
> Error code: NS_ERROR_NET_INADEQUATE_SECURITY"
> 
> There is perhaps a more useful error message in the error console:
> 
> addons.thunderbird.net : server does not support RFC 5746, see CVE-2009-3555

Well, both messages are almost enough information to step into an
analysis and search for data on various internet web sites.

There are quite some web resources out there that explain what's going
wrong here (beside we don't know exactly why). I'm quoting from
https://support.mozilla.org/en-US/questions/1312785

-%<-

> NS_ERROR_NET_INADEQUATE_SECURITY indicates that the server initiates
> a HTTP/2 connection, but Firefox detects an invalid TLS configuration
> in the server response (server negotiated HTTP/2 with blacklisted
> cipher suites). This is likely not an issue with the certificate, but
> this is a problem with the server setup and there are invalid cipher
> suites for HTTP/2 claimed (INADEQUATE_SECURITY).>
> http://httpwg.org/specs/rfc7540.html#TLSUsage There might also be
> other software that acts as a MITM and is interfering. When HTTP/2 is
> enabled and used then the requirements are much stricter than with
> HTTP/1.1 You can get the NS_ERROR_NET_INADEQUATE_SECURITY error
> message in case the server isn't configured properly.>
> A workaround to fix this ANNOYING issue is;
> network.http.spdy.enabled.http2 = false in about:config

->%-

So, to recap:
The server is sending over a HTTP/2 connection, but Thunderbird, or more
precisely the NSS3 library (depending on the configuration of
Thunderbird) is detecting some invalid TLS data and is
stopping the communication by presenting this message about
NS_ERROR_NET_INADEQUATE_SECURITY because the settings are that strict to
not going further.

> The problem also appears when trying to load other pages or using
> certain add-ons (for example, calendar-google-provider).
> 
> The problem goes away if one sets network.http.spdy.enforce-tls-profile
> to false in the preferences. This makes me think that there is an issue
> with the TLS library.

This isn't a problem solution, it's a workaround that disables the TLS
validation check. And if Thunderbird is instructed to ignore any
security settings related to SSL/TLS it's not really surprising that the
previously seen issues seems to have gone.

Currently I've no real idea what's the reason why 78.11.0 is working
differently than the previous version 78.10.x.
And further more it's also possible that the external resources have a
real problem regarding the TLS settings. This needs clarification and
analysis of the underlying data flow.

Both Thunderbird versions 78.10.x and 78.11.x are using the same
underlying libnss3 version, that hasn't changed since 2021-02-18. That's
the main difference to the Thunderbird version in stable-security, there
we use the internal shipped NSS3 source to build the packages and so far
we haven't seen bug reports from stable users.

The build checks for a minimum required NSS3 version.

> 0:10.34 checking for nss >= 3.53.1... yes

In the archive we have 3.61 so it's clear the check is passing. The
upstream source for Thunderbird 78.11.0 comes with NSS3 version 3.51.1
and this hasn't changed since the introducing of Thunderbird ESR series
78.x.

In can currently only think of some other different internal behavior of
78.11.0 together with NSS3 from the system.
The changelog from Mozilla for 78.11.0 isn't giving any hint that some
upstream modification might be the reason for the different behavior.

Closed bug reports between 78.10.2 and 78.11.0

> https://bugzilla.mozilla.org/buglist.cgi?bug_id=1709046%2C1697252%2C1712469%2C1700279%2C1695592%2C1709492%2C1704161%2C1707569%2C1712610%2C1712632%2C1712293

Closed bug reports between 78.10.1 and 78.10.2

> https://bugzilla.mozilla.org/buglist.cgi?bug_id=1673241%2C1701924%2C1709261%2C1654893%2C1658216%2C1701908%2C1707408%2C1702582%2C1697075%2C1707021%2C1691297%2C1701356%2C1710290%2C1692616%2C1671051%2C1686984%2C1681131%2C1673277%2C1679713%2C1704435

So to work around the problems users can do the following modification
to their profile settings.

Set network.http.spdy.enforce-tls-profile = false

If this isn't working this setting can set to false also

set network.http.spdy.enabled.http2 = false

But please note!
This decreases the transport security and should later get get reset to
the default, if not Thunderbird will use the insecure setting for ever!

-- 
Regards