Closed Bug 1323209 Opened 4 years ago Closed 4 years ago

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

Categories

(Core :: Networking: HTTP, defect)

50 Branch
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1290037
Tracking Status
firefox-esr45 --- affected
firefox50 --- wontfix
firefox51 --- unaffected
firefox52 --- unaffected
firefox53 --- unaffected

People

(Reporter: jbeich, Unassigned)

References

Details

(Keywords: regression)

Attachments

(1 file)

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
(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
(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
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.
Bisect first bad - https://hg.mozilla.org/projects/nss/rev/84b5417c3db8
Blocks: 1304762
Status: NEW → UNCONFIRMED
Ever confirmed: false
Keywords: regression
(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
Do you enable TLS 1.3?
Flags: needinfo?(jbeich)
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?
(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.
Flags: needinfo?(jbeich)
(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.
Flags: needinfo?(jbeich)
(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.
Flags: needinfo?(jbeich)
Summary: NS_ERROR_NET_INADEQUATE_SECURITY: Firefox < 52.0 TLS often fails --with-system-nss where NSS >= 3.28 → NS_ERROR_NET_INADEQUATE_SECURITY: Firefox < 51.0 TLS often fails --with-system-nss where NSS >= 3.28
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.
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
Assignee: nobody → nobody
Component: Libraries → Networking: HTTP
Product: NSS → Core
Version: trunk → Trunk
Version: Trunk → 50 Branch
(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.
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?
Backporting is of course fine for downstream, although official Firefox will not backport the fix to Firefox < 51.
--with-system-nss is also a downstream decision, so that's fine I guess.
(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 ?
(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.
(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..
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
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.
(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 ?
(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.
Resolution: WONTFIX → DUPLICATE
Duplicate of bug: 1290037
You need to log in before you can comment on or make changes to this bug.