从启用 HTTP/2 导致网站无法访问说起
文/Jerry Qu 最近好几个朋友在给网站开启 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」错误代码已经给出了两个提示:
通过 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):
注:上述配置中的 CHACHA20/POLY1305,由 Google 开发。以前需要使用 LibreSSL、BoringSSL 或者 CloudFlare 的 OpenSSL Patch 才能支持它,最新版的 OpenSSL 已经内置了对它的支持。 先来看看上述配置指定的 CipherSuite 具体有哪些(注:以下命令中的 openssl 版本是 LibreSSL 2.3.1):
运行结果如下: 0xCC,0x13 - ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=ChaCha20-Poly1305 再通过 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。 (编辑:PHP编程网 - 湛江站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |