从启用 HTTP/2 导致网站无法访问说起

1814次阅读  |  发布于5年以前

最近好几个朋友在给网站开启 HTTP/2 后，都遇到了无法访问的问题。其中有的网站只是 Firefox 无法访问，通过控制台网络面板可以看到请求被 Abort；有的网站不但 Firefox 无法访问，连 Chrome 也会跳到错误页，错误代码是「ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY」。诡异的是，只要去掉对 HTTP/2 的支持（例如去掉 Nginx listen 配置中的 http2）就一切正常。也就是说无法访问的现象只存在于 HTTPS + HTTP/2 的组合，单独提供 HTTPS 服务时就是好的。

这个问题比较有趣，本文除了告诉大家如何解决它之外，还会帮助大家弄清问题的来龙去脉。如果你只关心结论，直接看最后的小结即可。

首先，网站无法访问有很多种可能，一般要从基本项开始检查：

如果 TCP 连接能够建立，至少说明 Web Server 在运行，本地到 Web Server 网络也正常。如果还有问题，就要开始往应用层去排查，例如：

对于 HTTPS 网站，HTTP 和 TCP 中间多了一层 TLS。在浏览器发送 HTTP 报文前，还得先跟服务端建立 TLS 连接，这个过程非常复杂，也很容易出问题。例如：

关于部署 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。

本文就写到这里。大家平时遇到有关 HTTP(S)、HTTP/2 的问题，欢迎给我留言或者发邮件讨论。

专题「HTTP/2 相关」的其他文章 »

Copyright© 2013-2020

All Rights Reserved 京ICP备2023019179号-8