1323209 - NS_ERROR_NET_INADEQUATE_SECURITY: Firefox < 51.0 TLS often fails --with-system-nss where NSS >= 3.28

Status: RESOLVED DUPLICATE of bug 1290037

(Core :: Networking: HTTP, defect)

Description

[Jan Beich]

1. Install NSS 3.28 or later system-wide
2. Build Firefox 50 after adding --with-system-nss to .mozconfig
3. Open https://www.google.com/ncr (also via Tor)
4. Open https://duckduckgo.com
5. Downgrade NSS to 3.27 then rebuild at least security/* bits
6. Open https://www.google.com/ncr (also via Tor)

Notice 3rd step (unlike 6th) fails with:

  Your connection is not secure

  The website tried to negotiate an inadequate level of security.

  www.google.com uses security technology that is outdated and vulnerable to attack. An attacker could easily reveal information which you thought to be safe. The website administrator will need to fix the server first before you can visit the site.

  Error code: NS_ERROR_NET_INADEQUATE_SECURITY

Comment 1

[Eric Rescorla (:ekr)]

(In reply to Jan Beich from comment #0)
> 1. Install NSS 3.28 or later system-wide
> 2. Build Firefox 50 after adding --with-system-nss to .mozconfig
> 3. Open https://www.google.com/ncr (also via Tor)

I don't understand this. If you are testing with Tor, please test without Tor first.


> 4. Open https://duckduckgo.com
> 5. Downgrade NSS to 3.27 then rebuild at least security/* bits
> 6. Open https://www.google.com/ncr (also via Tor)
> 
> Notice 3rd step (unlike 6th) fails with:
> 
>   Your connection is not secure
> 
>   The website tried to negotiate an inadequate level of security.
> 
>   www.google.com uses security technology that is outdated and vulnerable to
> attack. An attacker could easily reveal information which you thought to be
> safe. The website administrator will need to fix the server first before you
> can visit the site.
> 
>   Error code: NS_ERROR_NET_INADEQUATE_SECURITY

Comment 2

[Jan Beich]

(In reply to Eric Rescorla (:ekr) from comment #1)
> I don't understand this. If you are testing with Tor, please test without
> Tor first.

Notice "also" as in vanilla connection fails just as much. Besides, Firefox 50 built against NSS 3.27 would fail as soon as NSS is upgraded to 3.28 - no rebuild is necessary.

$ firefox -no-remote -profile $(mktemp -d) https://www.google.com/ncr

Comment 3

[Jan Beich]

Reproduced on SeaMonkey 2.46 and Firefox ESR 45.6. Tracking flags are set to show how much damage NSS 3.28 can cause downstream that builds --with-system-nss.

Comment 4

[Jan Beich]

Bisect first bad - https://hg.mozilla.org/projects/nss/rev/84b5417c3db8

Comment 5

[Eric Rescorla (:ekr)]

(In reply to Jan Beich from comment #2)
> (In reply to Eric Rescorla (:ekr) from comment #1)
> > I don't understand this. If you are testing with Tor, please test without
> > Tor first.
> 
> Notice "also" as in vanilla connection fails just as much.

I did notice the "also" but frankly, this just isn't a very clear report.


> Besides, Firefox
> 50 built against NSS 3.27 would fail as soon as NSS is upgraded to 3.28 - no
> rebuild is necessary.
> 
> $ firefox -no-remote -profile $(mktemp -d) https://www.google.com/ncr

Comment 6

[Masatoshi Kimura [:emk]]

Do you enable TLS 1.3?

Comment 7

[Masatoshi Kimura [:emk]]

Additional questions:
1. If you flip the "network.http.spdy.enforce-tls-profile" pref, can you connect to Google?
2. If you can, what cipher suite and TLS version Google is negotiating?

Comment 8

[Jan Beich]

(In reply to Masatoshi Kimura [:emk] from comment #6)
> Do you enable TLS 1.3?

I did not touch TLS defaults. Both NSS 3.29 and NSS 3.28 exhibit the issue.

(In reply to Masatoshi Kimura [:emk] from comment #7)
> Additional questions:

> 1. If you flip the "network.http.spdy.enforce-tls-profile" pref, can you
> connect to Google?

Yes. Wikipedia is also affected and the workaround helps.

> 2. If you can, what cipher suite and TLS version Google is
> negotiating?

Google: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 128 bit keys, TLS 1.2
Wikipedia: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, 256 bit keys, TLS 1.2

Mainly tested after building Firefox against NSS 3.27 then reinstalling 3.28 or 3.29.
However, the ciphers don't change after building against NSS 3.29.

Comment 9

[Masatoshi Kimura [:emk]]

(In reply to Jan Beich from comment #8)
> Google: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 128 bit keys, TLS 1.2
> Wikipedia: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, 256 bit keys, TLS
> 1.2

Hm, these cipher suites should be qualified to use HTTP/2.

Could you reset "network.http.spdy.enforce-tls-profile" and take an HTTP log?
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

It will show why Firefox thinks the cipher suite is blacklisted.

Comment 10

[Jan Beich]

Attachment: MOZ_LOG=timestamp,rotate:200,nsHttp:5,nsSocketTransport:5,nsStreamPump:5,nsHostResolver:5 output

(In reply to Masatoshi Kimura [:emk] from comment #9)
> Could you reset "network.http.spdy.enforce-tls-profile" and take an HTTP log?
> https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

OK but I have no clue which module to log.

Comment 11

[Masatoshi Kimura [:emk]]

Thank you very much.
> 2016-12-14 12:11:49.725158 UTC - [Socket Thread]: I/nsHttp Http2Session::ConfirmTLSProfile 828236200 FAILED due to ECDH 255 < 256

So this is bug 1290037 that will be fixed since Firefox 51.
Unfortunately, disabling HTTP/2 or "network.http.spdy.enforce-tls-profile" would be the only options for older versions.

Comment 12

[Jan Beich]

(In reply to Masatoshi Kimura [:emk] from comment #11)
> So this is bug 1290037 that will be fixed since Firefox 51.
> Unfortunately, disabling HTTP/2 or "network.http.spdy.enforce-tls-profile"
> would be the only options for older versions.

Essentially, Firefox ESR, Thunderbird, SeaMonkey are broken --with-system-nss once NSS 3.28 is released. Letting other downstream peers know.

Comment 13

[Jan Alexander Steffens [:heftig]]

Thanks for the heads-up. Instead of disabling H2 or the profile enforcement, can we backport https://hg.mozilla.org/mozilla-central/rev/361ac226da2a to fix this?

Comment 14

[Masatoshi Kimura [:emk]]

Backporting is of course fine for downstream, although official Firefox will not backport the fix to Firefox < 51.

Comment 15

[Jan Alexander Steffens [:heftig]]

--with-system-nss is also a downstream decision, so that's fine I guess.

Comment 16

[Landry Breuil (:gaston)]

(In reply to Jan Steffens from comment #15)
> --with-system-nss is also a downstream decision, so that's fine I guess.

Err.. i'm not sure i'm understanding this correctly. Does this mean --with-system-nss is *not* a mozilla-supported configuration anymore, and we as downstream are on our own if we use it ?

From my reading of the bug report, this will only be an issue if a distributor updates to nss 3.28 while still shipping 50, but is fixed in 51 ?

Comment 17

[Masatoshi Kimura [:emk]]

(In reply to Landry Breuil (:gaston) from comment #16)
> From my reading of the bug report, this will only be an issue if a
> distributor updates to nss 3.28 while still shipping 50, but is fixed in 51 ?

Correct.

Comment 18

[Landry Breuil (:gaston)]

(In reply to Masatoshi Kimura [:emk] from comment #17)
> (In reply to Landry Breuil (:gaston) from comment #16)
> > From my reading of the bug report, this will only be an issue if a
> > distributor updates to nss 3.28 while still shipping 50, but is fixed in 51 ?
> 
> Correct.

Thanks for the confirmation. Given that mozilla has often been a bit late at shipping proper nss releases for distributors (ie already commited to m-c/m-a/m-b/m-r, marked as a version requirement in autoconf, tagged in hg with _RTM, but no proper standalone tarball) i suppose we'll be able to deal with it..

Comment 19

[Jan Beich]

After Firefox 51 release mozilla-esr45 and SeaMonkey (even with bug 1294433) would remain unfixed.  In SeaMonkey 2.46 case using bundled NSS isn't an option due to CVE-2016-9074, for 2.40 (current) it's worse: CVE-2016-2834, CVE-2016-1979, CVE-2016-1950

Comment 20

[Mike Hommey [:glandium]]

I don't see why this shouldn't be backported to esr45. Just ask for approval and see what the release managers have to say.

Comment 21

[Landry Breuil (:gaston)]

(In reply to Jan Beich from comment #8)
> Mainly tested after building Firefox against NSS 3.27 then reinstalling 3.28
> or 3.29.
> However, the ciphers don't change after building against NSS 3.29.

Wait, you got me puzzled here. If i look at https://hg.mozilla.org/projects/nss, i dont see a 3.28 or 3.29 'release'. Do you mean 'installing 3.28 from the tip of NSS_3_28_BRANCH or installing 3.29 from the tip of default branch', or you're talking about the nss versions that are in m-c/m-a, or nss official development moved to another repo ?

Comment 22

[Jan Beich]

(In reply to Landry Breuil (:gaston) from comment #21)
As this bug was originally filed against NSS I meant tip of the respective branches or default if N/A. Adding a directory prefix, compressing the repo and feeding it to the port should be enough.