| 注册
请输入搜索内容

热门搜索

Java Linux MySQL PHP JavaScript Hibernate jQuery Nginx
jopen
9年前发布

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

最近好几个朋友在给网站开启 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 )。至此基本可以肯定,问题出在 CipherSuite 上。

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 开发。以前需要使用 LibreSSLBoringSSL 或者 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,原来服务端选定的套件是 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)

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

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

本文链接: 参与评论

-- EOF --

发表于 2016-01-17 02:33:52 ,并被添加「HTTP2、 HTTPS 、Nginx」标签,最后修改于 2016-01-17 02:33:52 。

本站部署于「 阿里云 ECS 」。如果你也要购买阿里云服务,可以使用我的九折推荐码  NY1Z0E (限新用户),多谢支持!

</div>

来自: https://imququ.com/post/why-tls-handshake-failed-with-http2-enabled.html

 本文由用户 jopen 自行上传分享,仅供网友学习交流。所有权归原作者,若您的权利被侵害,请联系管理员。
 转载本站原创文章,请注明出处,并保留原始链接、图片水印。
 本站是一个以用户分享为主的开源技术平台,欢迎各类分享!
 本文地址:https://www.open-open.com/lib/view/open1452990787433.html
HTTP 加密解密 Web服务器