Opened 8 years ago
Closed 8 years ago
Last modified 8 years ago
#794 closed defect (invalid)
HTTP/2 with ssl_ciphers and/or ssl_prefer_server_ciphers result into browser errors
|Reported by:||Owned by:|
When a Browser is capable to use http/2 and you use ssl_prefer_server_ciphers ( on; ) or ssl_ciphers ('ALL@STRENGTH'; ), the browser will end with handshake-errors.
SSL-Libary: LibreSSL 2.2.3 and OpenSSL 1.0.2.d tested - both affected
Chrome 45.0.2454.99 shows the following error:
Firefox 40.0.3 doesn't do anything on load, it just abort.
Currently the http2-feature is completly useless, because of the very weak ciphers (like 3DES as default). So this is a real blocker.
Change History (4)
comment:1 by , 8 years ago
comment:2 by , 8 years ago
|Status:||new → closed|
The HTTP/2 clients may have some restrictions regarding negotiated cipher suites. So when you're configuring ciphers, you're responsible to meet all the necessary requirements.
See RFC 7540, Appendix A. I'm closing this as a misconfiguration.
comment:3 by , 8 years ago
Well, I don't think this is a missconfiguration:
I use the following options:
The ssl_ciphers referer to:
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
DH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH/RSA Au=DH Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
DH-RSA-AES256-SHA256 TLSv1.2 Kx=DH/RSA Au=DH Enc=AES(256) Mac=SHA256
This should be all fine for http/2 according to your document.
When I set *one* of these both option, Chrome & Firefox fail at the https:// site. Which means to me, the handshake is not possible for TLS.
If theres only a issue with the ciphers-string the option "prefer_server_cipher" should not trigger the issue.
comment:4 by , 8 years ago
In my tests Chrome announces the following ciphers in the ClientHello handshake message:
Cipher Suites Length: 34 Cipher Suites (17 suites) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e) Cipher Suite: Unknown (0xcc14) Cipher Suite: Unknown (0xcc13) Cipher Suite: Unknown (0xcc15) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
(The "Unknown" ciphers are ChaCha20.)
There are no interceptions with the cipher list derived from your
ssl_ciphers string, and handshake failure is an expected result, regardless of the protocol used and
ssl_prefer_server_ciphersis set on, first supported by client cipher from
ssl_cipherslist will be used. As far as I can see, this results in ECDHE-RSA-AES256-SHA, at least with Chrome:
It is blacklisted by HTTP/2 though, as per RFC 7540, Appendix A. Not sure why it's on the list, but likely due to SHA1 used for MAC. Trivial change to reduce SHA1 ciphers priority fixes things:
Given the fact that by default nginx uses ciphers as preferred by a client (that is,
ssl_prefer_server_ciphersis off by default), I don't think that we need to do something special about it. Looks like just another aspect to consider when switching on