從啟用 HTTP/2 導(dǎo)致網(wǎng)站無法訪問說起

作者：Jerry Qu 2016-03-22 09:38:36

最近好幾個朋友在給網(wǎng)站開啟 HTTP/2 后，都遇到了無法訪問的問題。其中有的網(wǎng)站只是 Firefox 無法訪問，通過控制臺網(wǎng)絡(luò)面板可以看到請求被 Abort;有的網(wǎng)站不但 Firefox 無法訪問，連 Chrome 也會跳到錯誤頁，錯誤代碼是「ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY」。詭異的是，只要去掉對 HTTP/2 的支持(例如去掉 Nginx listen 配置中的 http2)就一切正常。也就是說無法訪問的現(xiàn)象只存在于 HTTPS + HTTP/2 的組合，單獨(dú)提供 HTTPS 服務(wù)時就是好的。

這個問題比較有趣，本文除了告訴大家如何解決它之外，還會幫助大家弄清問題的來龍去脈。如果你只關(guān)心結(jié)論，直接看最后的小結(jié)即可。

首先，網(wǎng)站無法訪問有很多種可能，一般要從基本項(xiàng)開始檢查：

網(wǎng)站 DNS 解析是否正常(可以通過 ping、nslookup、dig 等工具來排查);
是否網(wǎng)絡(luò)不通(可以通過能否訪問 imququ.com 來排查 ^_^);
TCP 連接能否建立(可以通過 telnet 來排查，例如 telnet imququ.com 443)；

如果 TCP 連接能夠建立，至少說明 Web Server 在運(yùn)行，本地到 Web Server 網(wǎng)絡(luò)也正常。如果還有問題，就要開始往應(yīng)用層去排查，例如：

是否因?yàn)橛蛎麤]備案被阻止(可以嘗試用 IP，或者換非標(biāo)準(zhǔn)端口訪問);
是否因?yàn)?Web 程序太慢，遲遲沒返回響應(yīng)(通過瀏覽器網(wǎng)絡(luò)面板可以看到請求狀態(tài)一直是 pending);
是否有響應(yīng)，只是內(nèi)容為空(根據(jù)響應(yīng)狀態(tài)碼，排查服務(wù)端配置或業(yè)務(wù)代碼);

對于 HTTPS 網(wǎng)站，HTTP 和 TCP 中間多了一層 TLS。在瀏覽器發(fā)送 HTTP 報(bào)文前，還得先跟服務(wù)端建立 TLS 連接，這個過程非常復(fù)雜，也很容易出問題。例如：

沒有合法的證書(已過期、域名不匹配等等，一般瀏覽器都會給出明確的提示。需要特別排查同 IP 部署多 HTTPS 站點(diǎn)時，由于客戶端不支持 SNI 導(dǎo)致的證書不合法問題);
使用了瀏覽器不支持的證書類型(例如沒有打 XP SP3 補(bǔ)丁的 IE6 不支持 SHA-2 證書);
使用了瀏覽器不支持的 TLS 協(xié)議版本(例如 IE6 默認(rèn)只支持 SSLv2 和 SSLv3);
使用了瀏覽器不支持的 CipherSuite(例如 ECDHE-ECDSA-CHACHA20-POLY1305 只有 Chrome 支持);

關(guān)于部署 HTTPS 時的一些注意事項(xiàng)，可以參考我之前的「對于關(guān)于啟用 HTTPS 的一些經(jīng)驗(yàn)分享(二)」這篇文章，這不是本文重點(diǎn)，故不展開討論。

總之前面列了這么多可能，跟本文要解決的問題基本沒有任何關(guān)系!如果是因?yàn)轫憫?yīng)遲遲沒有回來，或者是證書不合法導(dǎo)致的無法訪問，完全沒有道理不啟用 HTTP/2 就是好的。

實(shí)際上，Chrome 這個「ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY」錯誤代碼已經(jīng)給出了兩個提示：

與 HTTP/2 有關(guān)。SPDY 是 HTTP/2 的前身，這個錯誤碼應(yīng)該是從 SPDY 時代沿用下來的;
與 TLS 安全有關(guān)。對于有安全隱患的 HTTPS 站點(diǎn)，現(xiàn)代瀏覽器會阻止 TLS 握手成功。例如最新的 Chrome 48 會拒絕與「以 RC4 做為對稱加密算法的 CipherSuite」建立 TLS 連接;

通過 Wireshark 抓包可以看到：這個案例中，瀏覽器在 TLS 握手階段發(fā)送了「Encrypted Alert」，然后主動斷開了 TCP。TLS 連接都沒有建立成功，頁面當(dāng)然無法訪問了。

之前閱讀 HTTP/2 RFC 時，我了解到 HTTP/2 協(xié)議中對 TLS 有了更嚴(yán)格的限制：例如 HTTP/2 中只能使用 TLSv1.2+，還禁用了幾百種 CipherSuite(詳見：TLS 1.2 Cipher Suite Black List)。至此可以肯定，之所以出現(xiàn)這個錯誤，要么是服務(wù)端沒有啟用 TLSv1.2，要么是 CipherSuite 配置有問題。本案例中，服務(wù)端支持 TLSv1.2，只可能是后者有問題。

CipherSuite，也就是加密套件，在整個 TLS 協(xié)議中至關(guān)重要。

建立 TLS 連接時，瀏覽器需要在 Client Hello 握手中提供自己支持的 CipherSuite 列表和應(yīng)用協(xié)議列表(通過 TLS ALPN 擴(kuò)展)，服務(wù)端則通過 Server Hello 握手返回選定的 CipherSuite 和應(yīng)用協(xié)議。如果服務(wù)端選定的應(yīng)用協(xié)議是 HTTP/2，瀏覽器就需要檢查 CipherSuite 是否在 HTTP/2 的黑名單之中，如果存在就終止 TLS 握手。

當(dāng)然，如果瀏覽器本身不支持 HTTP/2，Client Hello 握手中的 ALPN 擴(kuò)展中就不會包含 h2(實(shí)際上，ALPN 擴(kuò)展都不一定存在)，服務(wù)端也不會選定 HTTP/2 做為后續(xù)應(yīng)用協(xié)議。實(shí)際上，這個過程就是 HTTP/2 協(xié)議協(xié)商機(jī)制。

HTTP/2 對 CipherSuite 有更嚴(yán)格的限制，用于承載 HTTP/1.1 加密流量的 CipherSuite，不一定能用于承載 HTTP/2 加密流量。這也導(dǎo)致之前運(yùn)行良好的 HTTPS 站點(diǎn)，在啟用 HTTP/2 后，可能會由于 CipherSuite 被禁用導(dǎo)致無法通過 HTTP/2 訪問。

明白了原理，再來看一個具體案例(注：本案例來自于本博客網(wǎng)友評論，via)：

在 Nginx 中配置以下 CipherSuite 并啟用 HTTP/2，在最新的 Firefox 中無法訪問：

在 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 開發(fā)。以前需要使用 LibreSSL、BoringSSL 或者 CloudFlare 的 OpenSSL Patch 才能支持它，最新版的 OpenSSL 已經(jīng)內(nèi)置了對它的支持(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

運(yùn)行結(jié)果如下：

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 中發(fā)送的 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 協(xié)商目的是找出兩端都支持的套件，也就是取出二者的交集：

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 協(xié)議中還禁用了好幾百個。把這部分去掉后只剩下：

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xC0,0x2F)

奇怪的是，好歹還有一個滿足所有條件的套件，為什么還是會握手失敗呢?通過 Wireshark 看一下 Server Hello 會發(fā)現(xiàn)：在這個案例中，通過 Firefox 訪問，服務(wù)端選定的套件是 0xC0,0x14，并不是 0xC0,0x2F。

Nginx 有一個 ssl_prefer_server_ciphers 配置，如果設(shè)置為 on，表示在協(xié)商 CipherSuite 時，算出交集后，會按照服務(wù)端配置的套件列表順序返回第一個，這樣可以提高安全性。而那份配置的 ssl_ciphers 中，0xC0,0x14 排在了 0xC0,0x2F 前面，開啟 ssl_prefer_server_ciphers 后，會使得被 HTTP/2 禁用的 0xC0,0x14 選中，從而導(dǎo)致最終 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 下無法訪問的問題。當(dāng)然，正如我在以往文章中多次強(qiáng)調(diào)的，配置 TLS 時務(wù)必參考權(quán)威文檔，例如：Mozilla 的推薦配置、CloudFlare 使用的配置。經(jīng)過測試，使用這兩份配置的 HTTPS 站點(diǎn)在啟用 HTTP/2 后都沒有問題。

簡單小結(jié)一下，對于能正常工作的 HTTPS 網(wǎng)站啟用 HTTP/2 后出現(xiàn)無法訪問的問題，請排查服務(wù)端這兩點(diǎn)配置：1)是否啟用了 TLSv1.2;2)是否正確配置了 CipherSuite。

本文就寫到這里。大家平時遇到有關(guān) HTTP(S)、HTTP/2 的問題，歡迎給我留言或者發(fā)郵件討論。

責(zé)任編輯：何妍來源： Jerry Qu的小站