开启HTTP/2导致网站无法访问说起
2023-12-27 分类： 网站建设
最近好几个朋友在给网站开启 HTTP/2 后，都遇到了无法访问的问题。其中有的网站只是 Firefox 无法访问，通过控制台网络面板可以看到请求被 Abort；有的网站不但 Firefox 无法访问，连 Chrome 也会跳到错误页，错误代码是「ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY」。诡异的是，只要去掉对 HTTP/2 的支持（例如去掉 Nginx listen 配置中的 http2）就一切正常。也就是说无法访问的现象只存在于 HTTPS + HTTP/2 的组合，单独提供 HTTPS 服务时就是好的。
这个问题比较有趣，本文除了告诉大家如何解决它之外，还会帮助大家弄清问题的来龙去脉。如果你只关心结论，直接看最后的小结即可。
首先，网站无法访问有很多种可能，一般要从基本项开始检查：
是否网络不通（可以通过能否访问 imququ.com 来排查 ^_^）；
网站 DNS 解析是否正常（可以通过 ping、nslookup、dig 等工具来排查）；
TCP 连接能否建立（可以通过 telnet 来排查，例如 telnet imququ.com 443）；
如果 TCP 连接能够建立，至少说明 Web Server 在运行，本地到 Web Server 网络也正常。如果还有问题，就要开始往应用层去排查，例如：
是否因为域名没备案被阻止（可以尝试用 IP，或者换非标准端口访问）；
是否因为 Web 程序太慢，迟迟没返回响应（通过浏览器网络面板可以看到请求状态一直是 pending）；
是否有响应，只是内容为空（根据响应状态码，排查服务端配置或业务代码）；
对于 HTTPS 网站，HTTP 和 TCP 中间多了一层 TLS。在浏览器发送 HTTP 报文前，还得先跟服务端建立 TLS 连接，这个过程非常复杂，也很容易出问题。例如：
没有合法的证书（已过期、域名不匹配等等，一般浏览器都会给出明确的提示。需要特别排查同 IP 部署多 HTTPS 站点时，由于客户端不支持 SNI 导致的证书不合法问题）；
使用了浏览器不支持的证书类型（例如没有打 XP SP3 补丁的 IE6 不支持 SHA-2 证书）；
使用了浏览器不支持的 TLS 协议版本（例如 IE6 默认只支持 SSLv2 和 SSLv3）；
使用了浏览器不支持的 CipherSuite（例如 ECDHE-ECDSA-CHACHA20-POLY1305 只有 Chrome 支持）；
关于部署 HTTPS 时的一些注意事项，可以参考我之前的「对于关于启用 HTTPS 的一些经验分享（二）」这篇文章，这不是本文重点，故不展开讨论。
总之前面列了这么多可能，跟本文要解决的问题基本没有任何关系！如果是因为响应迟迟没有回来，或者是证书不合法导致的无法访问，完全没有道理不启用 HTTP/2 就是好的。
实际上，Chrome 这个「ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY」错误代码已经给出了两个提示：
1.与 HTTP/2 有关。SPDY 是 HTTP/2 的前身，这个错误码应该是从 SPDY 时代沿用下来的；
2.与 TLS 安全有关。对于有安全隐患的 HTTPS 站点，现代浏览器会阻止 TLS 握手成功。例如最新的 Chrome 48 会拒绝与「以 RC4 做为对称加密算法的 CipherSuite」建立 TLS 连接；
通过 Wireshark 抓包可以看到：这个案例中，浏览器在 TLS 握手阶段发送了「Encrypted Alert」，然后主动断开了 TCP。TLS 连接都没有建立成功，页面当然无法访问了。
之前阅读 HTTP/2 RFC 时，我了解到 HTTP/2 协议中对 TLS 有了更严格的限制：例如 HTTP/2 中只能使用 TLSv1.2+，还禁用了几百种 CipherSuite。至此可以肯定，之所以出现这个错误，要么是服务端没有启用 TLSv1.2，要么是 CipherSuite 配置有问题。本案例中，服务端支持 TLSv1.2，只可能是后者有问题。
CipherSuite，也就是加密套件，在整个 TLS 协议中至关重要。
建立 TLS 连接时，浏览器需要在 Client Hello 握手中提供自己支持的 CipherSuite 列表和应用协议列表（通过 TLS ALPN 扩展），服务端则通过 Server Hello 握手返回选定的 CipherSuite 和应用协议。如果服务端选定的应用协议是 HTTP/2，浏览器就需要检查 CipherSuite 是否在 HTTP/2 的黑名单之中，如果存在就终止 TLS 握手。
当然，如果浏览器本身不支持 HTTP/2，Client Hello 握手中的 ALPN 扩展中就不会包含 h2（实际上，ALPN 扩展都不一定存在），服务端也不会选定 HTTP/2 做为后续应用协议。实际上，这个过程就是 HTTP/2 协议协商机制。
HTTP/2 对 CipherSuite 有更严格的限制，用于承载 HTTP/1.1 加密流量的 CipherSuite，不一定能用于承载 HTTP/2 加密流量。这也导致之前运行良好的 HTTPS 站点，在启用 HTTP/2 后，可能会由于 CipherSuite 被禁用导致无法通过 HTTP/2 访问。
明白了原理，再来看一个具体案例（注：本案例来自于本博客网友评论，via）：
在 Nginx 中配置以下 CipherSuite 并启用 HTTP/2，在最新的 Firefox 中无法访问：
ssl_ciphers ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
注：上述配置中的 CHACHA20/POLY1305，由 Google 开发。以前需要使用 LibreSSL、BoringSSL 或者 CloudFlare 的 OpenSSL Patch 才能支持它，最新版的 OpenSSL 已经内置了对它的支持。
先来看看上述配置指定的 CipherSuite 具体有哪些（注：以下命令中的 openssl 版本是 LibreSSL 2.3.1）：
openssl ciphers -V 'ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4' | column -t
运行结果如下：
0xCC,0x13 - ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=ChaCha20-Poly1305 Mac=AEAD 0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD 0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 0xC0,0x14 - ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD 0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 0xC0,0x13 - ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 0x00,0x9D - AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD 0x00,0x3D - AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 0x00,0x35 - AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 0x00,0x9C - AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD 0x00,0x3C - AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 0x00,0x2F - AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 0xC0,0x12 - ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1 0x00,0x0A - DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
再通过 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。
本文就写到这里。大家平时遇到有关 HTTP(S)、HTTP/2 的问题，欢迎给我留言或者发邮件讨论。
本文来源于成都网站建设公司与成都网站设计制作公司-创新互联成都公司！
这个问题比较有趣，本文除了告诉大家如何解决它之外，还会帮助大家弄清问题的来龙去脉。如果你只关心结论，直接看最后的小结即可。
首先，网站无法访问有很多种可能，一般要从基本项开始检查：
是否网络不通（可以通过能否访问 imququ.com 来排查 ^_^）；
网站 DNS 解析是否正常（可以通过 ping、nslookup、dig 等工具来排查）；
TCP 连接能否建立（可以通过 telnet 来排查，例如 telnet imququ.com 443）；
如果 TCP 连接能够建立，至少说明 Web Server 在运行，本地到 Web Server 网络也正常。如果还有问题，就要开始往应用层去排查，例如：
是否因为域名没备案被阻止（可以尝试用 IP，或者换非标准端口访问）；
是否因为 Web 程序太慢，迟迟没返回响应（通过浏览器网络面板可以看到请求状态一直是 pending）；
是否有响应，只是内容为空（根据响应状态码，排查服务端配置或业务代码）；
对于 HTTPS 网站，HTTP 和 TCP 中间多了一层 TLS。在浏览器发送 HTTP 报文前，还得先跟服务端建立 TLS 连接，这个过程非常复杂，也很容易出问题。例如：
没有合法的证书（已过期、域名不匹配等等，一般浏览器都会给出明确的提示。需要特别排查同 IP 部署多 HTTPS 站点时，由于客户端不支持 SNI 导致的证书不合法问题）；
使用了浏览器不支持的证书类型（例如没有打 XP SP3 补丁的 IE6 不支持 SHA-2 证书）；
使用了浏览器不支持的 TLS 协议版本（例如 IE6 默认只支持 SSLv2 和 SSLv3）；
使用了浏览器不支持的 CipherSuite（例如 ECDHE-ECDSA-CHACHA20-POLY1305 只有 Chrome 支持）；
关于部署 HTTPS 时的一些注意事项，可以参考我之前的「对于关于启用 HTTPS 的一些经验分享（二）」这篇文章，这不是本文重点，故不展开讨论。
总之前面列了这么多可能，跟本文要解决的问题基本没有任何关系！如果是因为响应迟迟没有回来，或者是证书不合法导致的无法访问，完全没有道理不启用 HTTP/2 就是好的。
实际上，Chrome 这个「ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY」错误代码已经给出了两个提示：
1.与 HTTP/2 有关。SPDY 是 HTTP/2 的前身，这个错误码应该是从 SPDY 时代沿用下来的；
2.与 TLS 安全有关。对于有安全隐患的 HTTPS 站点，现代浏览器会阻止 TLS 握手成功。例如最新的 Chrome 48 会拒绝与「以 RC4 做为对称加密算法的 CipherSuite」建立 TLS 连接；
通过 Wireshark 抓包可以看到：这个案例中，浏览器在 TLS 握手阶段发送了「Encrypted Alert」，然后主动断开了 TCP。TLS 连接都没有建立成功，页面当然无法访问了。
之前阅读 HTTP/2 RFC 时，我了解到 HTTP/2 协议中对 TLS 有了更严格的限制：例如 HTTP/2 中只能使用 TLSv1.2+，还禁用了几百种 CipherSuite。至此可以肯定，之所以出现这个错误，要么是服务端没有启用 TLSv1.2，要么是 CipherSuite 配置有问题。本案例中，服务端支持 TLSv1.2，只可能是后者有问题。
CipherSuite，也就是加密套件，在整个 TLS 协议中至关重要。
建立 TLS 连接时，浏览器需要在 Client Hello 握手中提供自己支持的 CipherSuite 列表和应用协议列表（通过 TLS ALPN 扩展），服务端则通过 Server Hello 握手返回选定的 CipherSuite 和应用协议。如果服务端选定的应用协议是 HTTP/2，浏览器就需要检查 CipherSuite 是否在 HTTP/2 的黑名单之中，如果存在就终止 TLS 握手。
当然，如果浏览器本身不支持 HTTP/2，Client Hello 握手中的 ALPN 扩展中就不会包含 h2（实际上，ALPN 扩展都不一定存在），服务端也不会选定 HTTP/2 做为后续应用协议。实际上，这个过程就是 HTTP/2 协议协商机制。
HTTP/2 对 CipherSuite 有更严格的限制，用于承载 HTTP/1.1 加密流量的 CipherSuite，不一定能用于承载 HTTP/2 加密流量。这也导致之前运行良好的 HTTPS 站点，在启用 HTTP/2 后，可能会由于 CipherSuite 被禁用导致无法通过 HTTP/2 访问。
明白了原理，再来看一个具体案例（注：本案例来自于本博客网友评论，via）：
在 Nginx 中配置以下 CipherSuite 并启用 HTTP/2，在最新的 Firefox 中无法访问：
ssl_ciphers ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
注：上述配置中的 CHACHA20/POLY1305，由 Google 开发。以前需要使用 LibreSSL、BoringSSL 或者 CloudFlare 的 OpenSSL Patch 才能支持它，最新版的 OpenSSL 已经内置了对它的支持。
先来看看上述配置指定的 CipherSuite 具体有哪些（注：以下命令中的 openssl 版本是 LibreSSL 2.3.1）：
openssl ciphers -V 'ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4' | column -t
运行结果如下：
0xCC,0x13 - ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=ChaCha20-Poly1305 Mac=AEAD 0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD 0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 0xC0,0x14 - ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD 0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 0xC0,0x13 - ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 0x00,0x9D - AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD 0x00,0x3D - AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 0x00,0x35 - AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 0x00,0x9C - AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD 0x00,0x3C - AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 0x00,0x2F - AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 0xC0,0x12 - ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1 0x00,0x0A - DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
再通过 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。
本文就写到这里。大家平时遇到有关 HTTP(S)、HTTP/2 的问题，欢迎给我留言或者发邮件讨论。
本文来源于成都网站建设公司与成都网站设计制作公司-创新互联成都公司！
文章名称：开启HTTP/2导致网站无法访问说起
新闻来源：/news39/310539.html
成都网站建设公司_创新互联，为您提供企业建站、定制开发、网页设计公司、网站建设、网站设计、网站导航
声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联
猜你还喜欢下面的内容
- 成都软件开发的开发流程有哪些呢? 2023-12-27
- 如何在网站设计中使用视觉上惊艳的网页？ 2023-12-27
- 网站推广得怎么推广网站才能为企业带来用户？ 2023-12-27
- 网站模板代码开发有哪些基础？制作网页代码大全！ 2023-12-27
- 成都竞价托管：提高转化率的5个步骤 2023-12-27
- 如何为您的服务器选择带宽 2023-12-27
- 美国Linux服务器SSL证书办理以及安装的方法 2023-12-26
- 多服务器环境的好处是什么？ 2023-12-27
- 成都网站建设的步骤是怎样的？ 2023-12-27
- 制作网站的教程有没有？怎样定制制作网站？(如何制作网站教程) 2023-12-27
- 成都建立网站需要哪些条件和流程？ 2023-12-27
- 高端网页定制开发推广好处是什么 2023-12-27
- 网站建设中如何设计出一个高端、大气、简约的网站？(自己如何做网站建设) 2023-12-26
- 听听成都app开发说4G才开始“4G+”又来了运营商玩什么花样？ 2023-12-26
- 网站优化之站长应该如何找到优质的外链？ 2023-12-26
- 百度网络推广有哪些优势？ 2023-12-26
- 成都网站制作在全国发展给力 2023-12-26
- 排版与布局在网页中的应用 2023-12-26
- 怎样可以快速的建设自己的网站？带你一起来看看(怎样可以快速建多人群) 2023-12-26