再通过 Wireshark 获得 Firefox 在 Client Hello 中发送的 CipherSuite 列表，如下：

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xC0,0x2B) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xC0,0x2F) TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xC0,0x0A) TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xC0,0x09) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xC0,0x13) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xC0,0x14) TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x00,0x33) TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x00,0x39) TLS_RSA_WITH_AES_128_CBC_SHA (0x00,0x2F) TLS_RSA_WITH_AES_256_CBC_SHA (0x00,0x35) TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x00,0x0A)

CipherSuite 协商目的是找出两端都支持的套件，也就是取出二者的交集：

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xC0,0x2F) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xC0,0x13) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xC0,0x14) TLS_RSA_WITH_AES_128_CBC_SHA (0x00,0x2F) TLS_RSA_WITH_AES_256_CBC_SHA (0x00,0x35) TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x00,0x0A)

乍一看选择余地还挺大，但别忘了，HTTP/2 协议中还禁用了好几百个。把这部分去掉后只剩下：

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xC0,0x2F)

奇怪的是，好歹还有一个满足所有条件的套件，为什么还是会握手失败呢？通过 Wireshark 看一下 Server Hello 会发现：在这个案例中，通过 Firefox 访问，服务端选定的套件是 0xC0,0x14，并不是 0xC0,0x2F。

Nginx 有一个 ssl_prefer_server_ciphers 配置，如果设置为 on，表示在协商 CipherSuite 时，算出交集后，会按照服务端配置的套件列表顺序返回第一个，这样可以提高安全性。而那份配置的 ssl_ciphers 中，0xC0,0x14 排在了 0xC0,0x2F 前面，开启 ssl_prefer_server_ciphers 后，会使得被 HTTP/2 禁用的 0xC0,0x14 选中，从而导致最终 HTTPS + HTTP/2 握手失败。

那为什么这份配置在 Chrome 中是正常的呢？Chrome 支持的 CipherSuite 如下，大家可以自己分析下。

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xC0,0x2B) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xC0,0x2F) TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x00,0x9E) TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xCC,0x14) TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xCC,0x13) TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xC0,0x0A) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xC0,0x14) TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x00,0x39) TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xC0,0x09) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xC0,0x13) TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x00,0x33) TLS_RSA_WITH_AES_128_GCM_SHA256 (0x00,0x9C) TLS_RSA_WITH_AES_256_CBC_SHA (0x00,0x35) TLS_RSA_WITH_AES_128_CBC_SHA (0x00,0x2F) TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x00,0x0A)

针对这个案例，将 Nginx 配置中的 0xC0,0x2F（ECDHE-RSA-AES128-GCM-SHA256）挪到 0xC0,0x14（ECDHE-RSA-AES256-SHA） 之前，即可解决最新 Firefox 下无法访问的问题。当然，正如我在以往文章中多次强调的，配置 TLS 时务必参考权威文档，例如：Mozilla 的推荐配置、CloudFlare 使用的配置。经过测试，使用这两份配置的 HTTPS 站点在启用 HTTP/2 后都没有问题。

简单小结一下，对于能正常工作的 HTTPS 网站启用 HTTP/2 后出现无法访问的问题，请排查服务端这两点配置：

1）是否启用了 TLSv1.2；

2）是否正确配置了 CipherSuite。

(责任编辑：admin)