#794 closed defect (invalid)
HTTP/2 with ssl_ciphers and/or ssl_prefer_server_ciphers result into browser errors
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | blocker | Milestone: | |
Component: | nginx-core | Version: | 1.9.x |
Keywords: | Cc: | ||
uname -a: | 4.1.6 | ||
nginx -V: | 1.9.5 |
Description
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.
Version 1.9.5
SSL-Libary: LibreSSL 2.2.3 and OpenSSL 1.0.2.d tested - both affected
Chrome 45.0.2454.99 shows the following error:
http://i.imgur.com/5iNF1mf.png
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 , 9 years ago
comment:2 by , 9 years ago
Resolution: | → invalid |
---|---|
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 , 9 years ago
Well, I don't think this is a missconfiguration:
I use the following options:
ssl_ciphers TLSv1.2:!AES128:!ECDSA:!aECDH:!RSA:!kEXP:!SRP:!3DES:!SSLv2:!SEED:!DES:!EXP:!CAMELLIA:!IDEA:!kDHd:!DSS:!PSK:!RC4:!aNULL@STRENGTH;
ssl_prefer_server_ciphers on;
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.
Please reopen.
comment:4 by , 9 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_ciphers
.
When
ssl_prefer_server_ciphers
is set on, first supported by client cipher fromssl_ciphers
list 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_ciphers
is 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 onssl_prefer_server_ciphers
.