从启用 HTTP/2 导致网站无法访问说起
运行结果如下: 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。 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 后出现无法访问的问题,请排查服务端这两点配置:
本文就写到这里。大家平时遇到有关 HTTP(S)、HTTP/2 的问题,欢迎给我留言或者发邮件讨论。 注:相关网站建设技巧阅读请移步到建站教程频道。 (编辑:应用网_丽江站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |