最近好几个朋友在给网站开启 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（详见：TLS 1.2 Cipher Suite Black List）。至此可以肯定，之所以出现这个错误，要么是服务端没有启用 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 已经内置了对它的支持（via）。

   先来看看上述配置指定的 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。