啟用HTTP/2導致HTTPS網站無法訪問

文章轉載自：從啟用 HTTP/2 導致網站無法訪問說起 （已獲原作者授權）

本站閱讀：啟用HTTP/2導致HTTPS網站無法訪問

本文介紹啟用HTTP/2後導致HTTPS網站無法訪問情況的解決方案，作者通過分析TCP、TLS通信協議以及加密套件等多個方面分析測試來解決這類問題，本文已獲原作者授權，詳情見下文章原文。

最近好幾個朋友在給網站開啟 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 http://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 就是好的。

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=AEAD0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA3840xC0,0x14 - ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA10xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA2560xC0,0x13 - ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA10x00,0x9D - AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD0x00,0x3D - AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA2560x00,0x35 - AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA10x00,0x9C - AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD0x00,0x3C - AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA2560x00,0x2F - AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA10xC0,0x12 - ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA10x00,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。