1483294 - Consider advertising h2 with TLS 1.3 enabled even if the TLS 1.2 mandatory cipher suite is disabled

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect, P3)

Description

[Darkspirit]

mozregression --launch 2014-11-28 --pref security.ssl3.ecdhe_rsa_aes_128_gcm_sha256:false -a https://servo.org
This is shortly after bug 1097320: F12 > Network. Reload page. Response header: X-Firefox-Spdy: "h2". h2 is working.

Regressed by bug 1121706:
mozregression --launch 2015-01-17 --pref security.ssl3.ecdhe_rsa_aes_128_gcm_sha256:false -a https://servo.org
We are not using h2, despite the connection to Cloudflare uses TLS 1.2 with ECDHE-ECDSA-AES128-GCM-SHA256 and would be qualified for h2.

Today:

TLS 1.2
Amazon supports ECDHE-RSA-AES256-GCM-SHA384 (https://www.hardenize.com/report/amazon.de#www_tls) and we want to use it. Because of their insane ciphersuite order we have to disable another cipher for this demonstration:
mozregression --launch 2018-08-14 --pref security.ssl3.ecdhe_rsa_aes_128_gcm_sha256:false security.ssl3.ecdhe_rsa_aes_128_sha:false -a https://www.amazon.de
Now we are using TLS 1.2 with ECDHE-RSA-AES256-GCM-SHA384, but without h2 (the bug).

TLS 1.3 draft 28:
Let's assume we are an institution and only wanted to allow PFS AEAD 256 bit, so everthing else than
security.tls13.aes_256_gcm_sha384
security.tls13.chacha20_poly1305_sha256
security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384
security.ssl3.ecdhe_ecdsa_chacha20_poly1305_sha256
security.ssl3.ecdhe_rsa_aes_256_gcm_sha384
security.ssl3.ecdhe_rsa_chacha20_poly1305_sha256
would be set to false:

mozregression --launch 2018-08-14 --pref security.ssl3.ecdhe_rsa_aes_128_gcm_sha256:false -a https://fastaim.de
This is IPv6-only, TLS 1.3, TLS_CHACHA20_POLY1305_SHA256, but Firefox does not advertise h2:
"Your browser does not support HTTP/2. Please use Mozilla Firefox."

As HTTP/2 should be reliably available for qualified ciphersuites,
I assume the fix would be to 
a) back out bug 1121706 if Google has fixed their server-side bug (bug 1121706 comment 20). Non compliant servers then might cause the error message from bug 1122642.
b) add a pref check for all the other PFS AEAD prefs, so that at least one is enabled. (Do you really want this?)

Thank you <3

Comment 1

[u408661]

Let me make sure I'm understanding this correctly - you're expecting firefox to offer h2 when offering tls1.3 regardless of the cipher suites enabled? (I don't disagree with the request, just making sure we have the same understanding of what's being asked.)

Just to note, we absolutely can not advertise h2 on a connection where we only offer tls1.2 or lower with that pref set to false - supporting that cipher suite on tls <= 1.2 is mandatory per rfc 7540 (https://tools.ietf.org/html/rfc7540#section-9.2.2)

Comment 2

[Darkspirit]

(In reply to Nicholas Hurley [:nwgh][:hurley] from comment #1)
> Let me make sure I'm understanding this correctly - you're expecting firefox to offer h2 when offering tls1.3 regardless of the cipher suites enabled?

Yes, that would be a consequence, thank you! :)

> Just to note, we absolutely can not advertise h2 on a connection where we only offer tls1.2 or lower with that pref set to false - supporting that cipher suite on tls <= 1.2 is mandatory per rfc 7540 (https://tools.ietf.org/html/rfc7540#section-9.2.2)

I try to explain how I understand it word by word:

>   A deployment of HTTP/2 over TLS 1.2 SHOULD NOT use any of the cipher
>   suites that are listed in the cipher suite black list (Appendix A).

If clients and servers don't make sure that they do not advertise/negotiate h2 if a blacklisted ciphersuite is listed before qualified ciphersuites, they are willingly taking the risk (https://trac.nginx.org/nginx/ticket/794) of breaking things:

>   Endpoints MAY choose to generate a connection error (Section 5.4.1)
>   of type INADEQUATE_SECURITY if one of the cipher suites from the
>   black list is negotiated.  A deployment that chooses to use a black-
>   listed cipher suite risks triggering a connection error unless the
>   set of potential peers is known to accept that cipher suite.

([:keeler] (use needinfo) from bug 1121706 comment 29)
> I have a remaining concern: even if we only offer h2 if the necessary suite is enabled, a misconfigured server could see that h2 is offered and try to use it while still picking a non-AEAD ciphersuite, right? In those cases, Firefox needs to do better than just mysteriously stopping the page load and not notifying the user in any way (like :emk said in bug 1121706 comment 22).

That was the actual problem in bug 1121706: You did not show an INADEQUATE_SECURITY error page, you just stopped the page load with no feedback.
bug 1122642 (showing an error page) has been the real fix over a year later:

(Nicholas Hurley [:nwgh][:hurley] from bug 1122642 comment 0)
> See bug 1121706 comment 29 - when we decide to send INADEQUATE_SECURITY because a server chose h2 when it shouldn't have, we should do better than just stopping the page load with no feedback. Let's add a net error page for that.

>   Implementations MUST NOT generate this error in reaction to the
>   negotiation of a cipher suite that is not on the black list.
>   Consequently, when clients offer a cipher suite that is not on the
>   black list, they have to be prepared to use that cipher suite with
>   HTTP/2.

ECDHE-RSA-AES256-GCM-SHA384 is offered by Firefox and not on the blacklist,
but Firefox not prepared to use it with HTTP/2
(because it does not advertise h2 at all if you manually disable security.ssl3.ecdhe_rsa_aes_128_gcm_sha256.)

Summarized: "Consequently" you MUST NOT deny h2 for a qualified ciphersuite, but SHOULD NOT use blacklisted ciphersuites (and MAY show an INADEQUATE_SECURITY error page).

>   The black list includes the cipher suite that TLS 1.2 makes
>   mandatory, 

We are interested in supporting HTTP/2. That means TLS_RSA_WITH_AES_128_CBC_SHA (https://tools.ietf.org/html/rfc5246#page-6) is blacklisted and we don't have a default/mandatory ciphersuite for TLS 1.2 at all anymore.

>              which means that TLS 1.2 deployments could have non-
>   intersecting sets of permitted cipher suites.  To avoid this problem
>   causing TLS handshake failures, deployments of HTTP/2 that use TLS
>   1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE]
>   with the P-256 elliptic curve [FIPS186].

Focusing on the term "TLS handshake failures" it sounds more like such a situation:
The client only supports ECDHE-RSA-AES256-GCM-SHA384:AES256-SHA *by default*
but the server only      ECDHE-RSA-AES128-GCM-SHA384:AES128-SHA *by default*,
so in their best interest to be able to
1. talk TLS (as we don't have a default/mandatory ciphersuite anymore) and to
2. talk HTTP/2
to each other, http/2 software MUST support ECDHE-RSA-AES128-GCM-SHA384 *by default* (which is now the new default/mandatory ciphersuite).

Firefox complies with that by supporting ECDHE-RSA-AES128-GCM-SHA384 *by default*.

Therefore I see bug 1121706 as a non-compliant hotfix for some users who manually disabled the suggested ciphersuite (the reporter disabled ECDHE because of mistrusting the NSA curves) and ran into INADEQUATE_SECURITY without seeing an error page (before bug 1122642).
Bug 1121706 should be backed out and, if you want to take the "SHOULD NOT use blacklisted ciphersuites" seriously,
you could add a check for not offering support for h2 if
1. no qualified ciphersuite is enabled at all and
2. no blacklisted ciphersuite is listed before a qualified one (you don't need to check this as Firefox doesn't have an insane ciphersuite order like Amazon).

Today, in contrast to 3 years ago, we also have ECDHE-{RSA,ECDSA}-AES256-GCM-SHA384, CHACHA20 and X25519.

If users [foolishly] disable secure ciphersuites to only use ancient ones, but without disabling network.http.spdy.enabled.http2 as well, they should get and enjoy their INADEQUATE_SECURITY error page. ;D

With above in mind, I can't understand why offering support for h2 should be denied if a client [only] supports h2-qualified ciphersuites [as most-preferred ciphersuites] for TLS 1.2.
I hope this wasn't completely mistaken.

Comment 3

[u408661]

Ah, ok. I see you want us to advertise h2 so long as any compliant cipher suite is available, regardless of TLS versions being advertised. Like I said in my previous comment, I'm 100% on board with advertising h2 regardless so long as we're advertising TLS 1.3 (assuming no servers barf at us for not having the mandatory suite enabled even though TLS 1.3 is offered), I can't justify doing so if (for whatever reason) Firefox has also been configured to only advertise TLS 1.2 or lower.

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #2)
> With above in mind, I can't understand why offering support for h2 should be
> denied if a client [only] supports h2-qualified ciphersuites [as
> most-preferred ciphersuites] for TLS 1.2.
> I hope this wasn't completely mistaken.

Let me copy/paste the relevant part of 7540 section 9.2.2:

> deployments of HTTP/2 that use TLS
> 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE]
> with the P-256 elliptic curve [FIPS186].

In other words, if we're using TLS 1.3, then we can offer whatever suites we want (as all the TLS 1.3 suites are A-OK in terms of security properties), but if we're using TLS 1.2 we absolutely have to offer the mandatory suite if we're offering h2 in ALPN. If we don't, any server is perfectly within its rights to tell us to go away.

Now, the use of the word "use" in the spec makes this language a bit fuzzy (and is why I want to make sure we have adequate testing before landing any change to loosen our behaviour here). Does it mean (1) we MUST offer the mandatory suite if we're offering TLS 1.2 at all, or (2) we MUST offer the mandatory suite *only if* we're not offering anything newer than TLS 1.2? Different people can interpret that in different ways, and if anyone's interpreting it strictly (version 1 of my options), then regardless of if we negotiate TLS 1.3, they may end up shutting down the connection.

So, here's what I'm going to do: use this bug to enable advertising h2 if TLS 1.3 is enabled regardless of the TLS 1.2 mandatory suite being enabled. This will (potentially, assuming nothing breaks on the wider internet) have the added advantage of allowing TLS 1.2 h2 connections to be made if we don't have the mandatory suite enabled, but only if TLS 1.3 is enabled (in other words, if you reduce your ssl max version to TLS 1.2, we will still require the mandatory suite).

Comment 4

[Darkspirit]

(In reply to Nicholas Hurley [:nwgh][:hurley] from comment #3)
> Does it mean (1) we MUST offer the mandatory suite if we're offering TLS 1.2 at all, or (2) we MUST offer the mandatory suite *only if* we're not offering anything newer than TLS 1.2?

Firefox must support the mandatory suite for TLS 1.2.

> Let me copy/paste the relevant part of 7540 section 9.2.2:
> 
> > deployments of HTTP/2 that use TLS
> > 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE]
> > with the P-256 elliptic curve [FIPS186].

Your quote looks like as if this ciphersuite must be enabled at any time to be able to use HTTP/2.

But it says: To prevent "TLS handshake failures" we have to replace the now forbidden default ciphersuite of TLS 1.2 with a new common default ciphersuite for TLS 1.2 for all implementations that are interested in supporting HTTP/2:

>   The black list includes the cipher suite that TLS 1.2 makes
>   mandatory, which means that TLS 1.2 deployments could have non-
>   intersecting sets of permitted cipher suites.  To avoid this problem
>   causing TLS handshake failures, deployments of HTTP/2 that use TLS
>   1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE]
>   with the P-256 elliptic curve [FIPS186].


TLS 1.2:
Software MUST support AES128-SHA to have a widespread compatible ciphersuite for TLS 1.2.
You can still use TLS 1.2 if a client or server owner manually disabled AES128-SHA and other TLS 1.2 ciphersuites are supported. You might run into SSL_ERROR_NO_CYPHER_OVERLAP.

HTTP/2 and TLS 1.2:
Software SHOULD NOT use blacklisted ciphers like AES128-SHA.
Software MUST support ECDHE-RSA-AES128-GCM-SHA256 to have a widespread compatible ciphersuite for HTTP/2.
You can still use HTTP/2 if a client or server owner manually disabled ECDHE-RSA-AES128-GCM-SHA256 and another h2-compatible TLS 1.2 ciphersuite is supported.
(I think at that time ECDHE-ECDSA-AES128-GCM-SHA256 was the only other widespread alternative.)
In any case it's possible to run into INADEQUATE_SECURITY if the relevant ciphersuite list preferred a blacklisted ciphersuite.

> So, here's what I'm going to do: use this bug to enable advertising h2 if TLS 1.3 is enabled regardless of the TLS 1.2 mandatory suite being enabled. This will (potentially, assuming nothing breaks on the wider internet) have the added advantage of allowing TLS 1.2 h2 connections to be made if we don't have the mandatory suite enabled, but only if TLS 1.3 is enabled (in other words, if you reduce your ssl max version to TLS 1.2, we will still require the mandatory suite).

https://trac.nginx.org/nginx/ticket/794
If an nginx server is configured to support h2 and TLS 1.2 with ECDHE-RSA-AES256-SHA, any user might see an INADEQUATE_SECURITY error.

bug 1121706 protects against one case of this problem:
Someone manually disabled ECDHE-RSA-AES128-GCM-SHA256 in Firefox and Firefox advertised h2 and TLS 1.0 to 1.2:
If then an nginx server supported h2 and TLS 1.2 with ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA, they would negotiate TLS 1.2 with ECDHE-RSA-AES128-SHA, but the user doesn't see an standard-compliant INADEQUATE_SECURITY error
because h2 was completely disabled before as hotfix as there was no INADEQUATE_SECURITY error page implemented at that time.
That hotfix caused being non-compliant in other H2 use cases as well.

Hopefully this is not completely wrong:
But if you always advertise h2 if TLS 1.3 is enabled in Firefox (which it already is), those five users would run into that error again if a server only supports TLS 1.2 (but at least they would now see an error message).
If they disabled TLS 1.3 in Firefox, they wouldn't see the error message anymore because Firefox just refused to offer h2 in that case.

It would be fatal to introduce an incentive to those five users to disable TLS 1.3 to get back to the non-compliant behavior.

If you look at all duplicates of bug 1121706 you see that they all have disabled security.ssl3.ecdhe_rsa_aes_128_gcm_sha256
without disabling network.http.spdy.enabled.http2. It is fully intended by the HTTP/2 standard that this would cause an INADEQUATE_SECURITY error. bug 1122642 added the error page a year later. The error message could link to a SUMO article that explains how to fix [messed up] prefs.

Comment 5

[u408661]

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #4)
> (In reply to Nicholas Hurley [:nwgh][:hurley] from comment #3)
> > Does it mean (1) we MUST offer the mandatory suite if we're offering TLS 1.2 at all, or (2) we MUST offer the mandatory suite *only if* we're not offering anything newer than TLS 1.2?
> 
> Firefox must support the mandatory suite for TLS 1.2.

My question was rhetorical (and your answer provides no clarity, it just restates what the spec says).

> You can still use HTTP/2 if a client or server owner manually disabled
> ECDHE-RSA-AES128-GCM-SHA256 and another h2-compatible TLS 1.2 ciphersuite is
> supported.

Not according to the spec - it's a MUST to support that suite if you're going to use h2 on TLS 1.2 (even if that suite is not, ultimately, the one chosen). But again, there is no clarity in the spec on what "use" means. So we have to make our best (safest) guess, which is what we have done in disabling h2 support if the mandatory cipher suite is disabled.

> In any case it's possible to run into INADEQUATE_SECURITY if the relevant
> ciphersuite list preferred a blacklisted ciphersuite.

Yes. C'est la vie. Doesn't mean we shouldn't still be spec-compliant.

> Someone manually disabled ECDHE-RSA-AES128-GCM-SHA256 in Firefox and Firefox
> advertised h2 and TLS 1.0 to 1.2:
> If then an nginx server supported h2 and TLS 1.2 with
> ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA, they would negotiate TLS
> 1.2 with ECDHE-RSA-AES128-SHA, but the user doesn't see an
> standard-compliant INADEQUATE_SECURITY error
> because h2 was completely disabled before as hotfix as there was no
> INADEQUATE_SECURITY error page implemented at that time.

Correct, because had we advertised h2 with the mandatory suite disabled (which we were doing before the fix landed), then we would not be spec-compliant. We (and others implementing h2) took a pretty hard line on spec-compliance, to avoid h2 becoming yet another strictly defined but loosely implemented protocol.

> That hotfix caused being non-compliant in other H2 use cases as well.

I don't think that means what you think it means. Firefox not advertising h2 without the mandatory suite enabled is 100% spec compliant. Especially given that, prior to the TLS handshake, it's impossible to know what version of TLS will be used (though we can know what versions are possible). I'll also note that it's entirely legit for an implementation to be more restrictive in when it will offer h2 - offering a protocol for selection is entirely at the mercy of the client. If we felt like it, we could only offer h2 on Tuesdays in an October with 5 Sundays that also happens in a leap year, so long as we meet all the other requirements of the spec. (The fact that h2 is preffable in Firefox is a more realistic example of this.)

> If you look at all duplicates of bug 1121706 you see that they all have
> disabled security.ssl3.ecdhe_rsa_aes_128_gcm_sha256
> without disabling network.http.spdy.enabled.http2. It is fully intended by
> the HTTP/2 standard that this would cause an INADEQUATE_SECURITY error. bug
> 1122642 added the error page a year later. The error message could link to a
> SUMO article that explains how to fix [messed up] prefs.

It's intended by the spec that, should a NON-COMPLIANT implementation advertise h2 over TLS 1.2 with the mandatory suite disabled, an INADEQUATE_SECURITY error would be received. The spec also says that a COMPLIANT implementation will NOT advertise h2 over TLS 1.2 without the mandatory suite.

> It would be fatal to introduce an incentive to those five users to disable
> TLS 1.3 to get back to the non-compliant behavior.

On this, you are correct. And I'm not inclined to incent people to disable TLS 1.3. Then again, it's totally legit to use h2 over TLS 1.3 with the 1.2 mandatory suite disabled. Whether or not to do anything here will take further consideration and internal discussion. Even if the choice is to do something, though, I am fairly confident that "something" won't involve removing the check for the mandatory suite entirely.

Comment 6

[Darkspirit]

TLS 1.2+1.3, only modern ciphers, HTTP/2 works:
mozregression --launch 2018-08-14 -a https://www.ssllabs.com/ssltest/viewMyClient.html#protocol_tls1_3_label --pref security.tls.version.min:3 security.ssl3.rsa_des_ede3_sha:false security.ssl3.rsa_aes_128_sha:false security.ssl3.rsa_aes_256_sha:false security.ssl3.dhe_rsa_aes_128_sha:false security.ssl3.dhe_rsa_aes_256_sha:false security.ssl3.ecdhe_rsa_aes_128_sha:false security.ssl3.ecdhe_rsa_aes_256_sha:false security.ssl3.ecdhe_ecdsa_aes_128_sha:false security.ssl3.ecdhe_ecdsa_aes_256_sha:false

TLS 1.2+1.3, only modern 256 bit ciphers, HTTP/2 does not work:
mozregression --launch 2018-08-14 -a https://www.ssllabs.com/ssltest/viewMyClient.html#protocol_tls1_3_label --pref security.tls.version.min:3 security.ssl3.rsa_des_ede3_sha:false security.ssl3.rsa_aes_128_sha:false security.ssl3.rsa_aes_256_sha:false security.ssl3.dhe_rsa_aes_128_sha:false security.ssl3.dhe_rsa_aes_256_sha:false security.ssl3.ecdhe_rsa_aes_128_sha:false security.ssl3.ecdhe_rsa_aes_256_sha:false security.ssl3.ecdhe_ecdsa_aes_128_sha:false security.ssl3.ecdhe_ecdsa_aes_256_sha:false security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256:false security.ssl3.ecdhe_rsa_aes_128_gcm_sha256:false security.tls13.aes_128_gcm_sha256:false

TLS 1.0 - 1.3, only 256 bit ciphers, HTTP/2 does not work:
mozregression --launch 2018-08-14 -a https://www.ssllabs.com/ssltest/viewMyClient.html#protocol_tls1_3_label --pref security.ssl3.rsa_des_ede3_sha:false security.ssl3.rsa_aes_128_sha:false security.ssl3.dhe_rsa_aes_128_sha:false security.ssl3.dhe_rsa_aes_256_sha:false security.ssl3.ecdhe_rsa_aes_128_sha:false security.ssl3.ecdhe_ecdsa_aes_128_sha:false security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256:false security.ssl3.ecdhe_rsa_aes_128_gcm_sha256:false security.tls13.aes_128_gcm_sha256:false

https://searchfox.org/mozilla-central/rev/5dbfd833bbb114afe758db4d4bdbc5b13bcc33ef/netwerk/protocol/http/nsHttpHandler.cpp#1832
A precise solution would be to check once after startup if all blacklisted ciphersuites are disabled as well if security.ssl3.ecdhe_rsa_aes_128_gcm_sha256 has been disabled. A low priority workaround might be a pref to enforce h2 support.

Amazon has a wrong ciphersuite order which would break HTTP/2 sooner: https://www.hardenize.com/report/amazon.com#www_tls
If bug 1121706 would be backed out and a user disabled security.ssl3.ecdhe_rsa_aes_128_gcm_sha256, ECDHE-RSA-AES128-SHA might be negotiated and could cause INADEQUATE_SECURITY. It would be a worse user experience, as least users would know how to  resolve the problem by setting other prefs. You want to avoid this for understandable reasons. The correct fix should be done server-side.

Comment 7

[Darkspirit]

I just saw your comment.

(In reply to Nicholas Hurley [:nwgh][:hurley] from comment #5)
> Then again, it's totally legit to use h2 over TLS 1.3 with the 1.2 mandatory suite disabled. Whether or not to do anything here will take further consideration and internal discussion.

Yeah, thank you for having a thought about it!

> Even if the choice is to do something, though, I am fairly confident that "something" won't involve removing the check for the mandatory suite entirely.

Yes, by reading and testing through this I realized that it should be kept and only be improved a bit. Thanks!

Comment 8

[Darkspirit]

Attachment: Screenshot_20180816_185218.png

(In reply to Nicholas Hurley [:nwgh][:hurley] from comment #5)
> (In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #4)
> > (In reply to Nicholas Hurley [:nwgh][:hurley] from comment #3)
> > > Does it mean (1) we MUST offer the mandatory suite if we're offering TLS 1.2 at all, or (2) we MUST offer the mandatory suite *only if* we're not offering anything newer than TLS 1.2?
> > 
> > Firefox must support the mandatory suite for TLS 1.2.
> 
> My question was rhetorical (and your answer provides no clarity, it just restates what the spec says).

(1) and (2) contains "MUST offer" and that's not what the spec says. I should have written: "Neither: Firefox must support the mandatory suite for TLS 1.2."

---

Chrome Dev 70 is spec-compliant:
google-chrome-unstable --cipher-suite-blacklist=0xc02f https://www.amazon.com/ https://www.ssllabs.com/ssltest/viewMyClient.html
=> ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY

https://www.hardenize.com/report/amazon.com#www_tls
Amazon is not spec-compliant by accepting h2 even a blacklisted ciphersuite has been negotiated. They should fix their ciphersuite order or a client who disabled ECDHE-RSA-AES128-GCM-SHA256 has to disable ECDHE-RSA-AES128-SHA256 as well to be able to connect to them:
google-chrome-unstable --cipher-suite-blacklist=0xc02f,0xc013 https://www.amazon.com/ https://www.ssllabs.com/ssltest/viewMyClienhtml
=> TLS 1.2 + ECDHE-RSA-AES256-GCM-SHA384 + HTTP/2

Comment 9

[Darkspirit]

> has to disable ECDHE-RSA-AES128-SHA256 as well
Sorry, I meant ECDHE-RSA-AES128-SHA.

Comment 10

[Darkspirit]

Now, experiencing Chrome's behavior which is spec-compliant and makes incentives to re-enable modern ciphersuites I have to come back to comment 0. At the moment there is no option to just have http/2 for some modern TLS configurations like it is possible with Chrome.

(In reply to Nicholas Hurley [:nwgh][:hurley] from comment #5)
> I'll also note that it's entirely legit for an implementation to be more restrictive in when it will offer h2 - offering a protocol for selection is entirely at the mercy of the client. If we felt like it, we could only offer h2 on Tuesdays in an October with 5 Sundays that also happens in a leap year, so long as we meet all the other requirements of the spec. (The fact that h2 is preffable in Firefox is a more realistic example of this.)

Your comment implies that hundreds of users might have disabled security.ssl3.ecdhe_rsa_aes_128_gcm_sha256. Especially those users who disabled *all* ECDHE ciphersuites because of mistrusting NSA curves are mostly using plain RSA on the web which is a privacy problem.

It would be good to let them run into the intended error page instead of still making their legacy configurations compatible to non-compliant server configurations. Again, today we have X25519 and Google additionally offers Chacha, ECDSA and TLS 1.3. There is no good reason to still disable h2 for users who configured Firefox to use TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA or even TLS_RSA_WITH_AES_128_CBC_SHA (orange on https://www.hardenize.com/report/google.com#www_tls) while completely denying h2 for some modern configurations.

Comment 11

[u408661]

"MUST support" is, effectively, "MUST offer", as there is no other way to tell if your peer supports something if they don't offer it.

I would argue that chrome is not spec-compliant here (and it wouldn't be the first time they're not spec-compliant for h2), given the MUST support in section 9.2.2 (chrome, as configured in your test, does not support the mandatory suite).

Anyway, I am putting this bug back to the purpose I changed it to a couple days back - consider offering h2 with no limitations when we're offering TLS 1.3. As I said, this will take some consideration and internal discussion to think through the implications of that (and therefore if it's something we really want to do).

Comment 12

[Darkspirit]

(In reply to Nicholas Hurley [:nwgh][:hurley] from comment #11)
> "MUST support" is, effectively, "MUST offer", as there is no other way to tell if your peer supports something if they don't offer it.

No, as you can even use TLS 1.2 if you don't offer AES128-SHA, as the standard only requires software to support it by default.

> I would argue that chrome is not spec-compliant here (and it wouldn't be the first time they're not spec-compliant for h2), given the MUST support in section 9.2.2 (chrome, as configured in your test, does not support the mandatory suite).
> 
> Anyway, I am putting this bug back to the purpose I changed it to a couple days back - consider offering h2 with no limitations when we're offering TLS 1.3. As I said, this will take some consideration and internal discussion to think through the implications of that (and therefore if it's something we really want to do).

Why are you not recognising what the spec says word-for-word, my comparison of TLS 1.2 with HTTP/2+TLS1.2 and current negative incentives?

You changed the title of this regression report to a different topic.
If you would check for security.tls.version.max;4 you would introduce a behavior like Chrome (like if you would backout bug 1121706), but otherwise this weird behavior and its negative incentives would be kept for people who manually set security.tls.version.max to 3.
I would like if others could comment on this issue before you change the sense of my report. Thanks

Comment 13

[Darkspirit]

Attachment: Edge.png

Chrome makes the right incentives against self-harming client-side configs and non-compliant server configurations and shows the INADEQUATE_SECURITY error.
= Full compliant.

Firefox prevents the use of HTTP/2 with some modern configurations (weird).
= Full compliant, but keeping the regression (bug 1121706) would be a product decision against H2 for some modern configurations, implying incentives for keeping self-harming (non PFS AEAD) client-side configs and non-compliant server configs.

Edge doesn't seem to implement the INADEQUATE_SECURITY error (MAY), offers and accepts HTTP/2 as long it's TLS 1.2 (ignores SHOULD NOT use blacklisted ciphers) and sees a server-side responsibility.
https://docs.microsoft.com/de-de/windows/desktop/SecAuthN/tls-cipher-suites-in-windows-10-v1709
= Not nice, but compliant.

Screenshot:
Open PowerShell as Administrator. Run these commands:
Disable-TlsCipherSuite -Name "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
Disable-TlsCipherSuite -Name "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"
Disable-TlsCipherSuite -Name "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384"
Disable-TlsCipherSuite -Name "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256"

To revert:
Enable-TlsCipherSuite -Name "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
Enable-TlsCipherSuite -Name "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"
Enable-TlsCipherSuite -Name "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384"
Enable-TlsCipherSuite -Name "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256"

Comment 14

[u408661]

Attachment: Bug 1483294 - Always advertise h2 if TLS 1.3 is being offered.

Previously (under TLS 1.2), we would avoid advertising h2 support if the
spec-mandatory suite was disabled. That suite is only required for TLS
1.2, though. We would like to offer h2 in more cases, so only check for
the mandatory suite if someone has turned off TLS 1.3.

Comment 15

[Dragana Damjanovic [:dragana]]

Comment on attachment 9004255 [details]
Bug 1483294 - Always advertise h2 if TLS 1.3 is being offered.

Dragana Damjanovic [:dragana] has approved the revision.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1ac72ebb37ef
Always advertise h2 if TLS 1.3 is being offered. r=dragana

Comment 17

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/1ac72ebb37ef