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

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

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

是否網(wǎng)絡(luò)不通（可以通過(guò)能否訪問(wèn) imququ.com 來(lái)排查 ^_^）；

網(wǎng)站 DNS 解析是否正常（可以通過(guò) ping、nslookup、dig 等工具來(lái)排查）；

TCP 連接能否建立（可以通過(guò) telnet 來(lái)排查，例如 telnet imququ.com 443）；

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

是否因?yàn)橛蛎麤](méi)備案被阻止（可以嘗試用 IP，或者換非標(biāo)準(zhǔn)端口訪問(wèn)）；

是否因?yàn)?Web 程序太慢，遲遲沒(méi)返回響應(yīng)（通過(guò)瀏覽器網(wǎng)絡(luò)面板可以看到請(qǐng)求狀態(tài)一直是 pending）；

是否有響應(yīng)，只是內(nèi)容為空（根據(jù)響應(yīng)狀態(tài)碼，排查服務(wù)端配置或業(yè)務(wù)代碼）；

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

沒(méi)有合法的證書(shū)（已過(guò)期、域名不匹配等等，一般瀏覽器都會(huì)給出明確的提示。需要特別排查同 IP 部署多 HTTPS 站點(diǎn)時(shí)，由于客戶(hù)端不支持 SNI 導(dǎo)致的證書(shū)不合法問(wèn)題）；

使用了瀏覽器不支持的證書(shū)類(lèi)型（例如沒(méi)有打 XP SP3 補(bǔ)丁的 IE6 不支持 SHA-2 證書(shū)）；

使用了瀏覽器不支持的 TLS 協(xié)議版本（例如 IE6 默認(rèn)只支持 SSLv2 和 SSLv3）；

使用了瀏覽器不支持的 CipherSuite（例如 ECDHE-ECDSA-CHACHA20-POLY1305 只有 Chrome 支持）；

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

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

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

1.與 HTTP/2 有關(guān)。SPDY 是 HTTP/2 的前身，這個(gè)錯(cuò)誤碼應(yīng)該是從 SPDY 時(shí)代沿用下來(lái)的；

2.與 TLS 安全有關(guān)。對(duì)于有安全隱患的 HTTPS 站點(diǎn)，現(xiàn)代瀏覽器會(huì)阻止 TLS 握手成功。例如最新的 Chrome 48 會(huì)拒絕與「以 RC4 做為對(duì)稱(chēng)加密算法的 CipherSuite」建立 TLS 連接；

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

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

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

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

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

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

明白了原理，再來(lái)看一個(gè)具體案例（注：本案例來(lái)自于本博客網(wǎng)友評(píng)論，via）：

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

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

先來(lái)看看上述配置指定的 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

再通過(guò) 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é)議中還禁用了好幾百個(gè)。把這部分去掉后只剩下：

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xC0,0x2F)

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

Nginx 有一個(gè) ssl_prefer_server_ciphers 配置，如果設(shè)置為 on，表示在協(xié)商 CipherSuite 時(shí)，算出交集后，會(huì)按照服務(wù)端配置的套件列表順序返回第一個(gè)，這樣可以提高安全性。而那份配置的 ssl_ciphers 中，0xC0,0x14 排在了 0xC0,0x2F 前面，開(kāi)啟 ssl_prefer_server_ciphers 后，會(huì)使得被 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)

針對(duì)這個(gè)案例，將 Nginx 配置中的 0xC0,0x2F（ECDHE-RSA-AES128-GCM-SHA256）挪到 0xC0,0x14（ECDHE-RSA-AES256-SHA） 之前，即可解決最新 Firefox 下無(wú)法訪問(wèn)的問(wèn)題。當(dāng)然，正如我在以往文章中多次強(qiáng)調(diào)的，配置 TLS 時(shí)務(wù)必參考權(quán)威文檔，例如：Mozilla 的推薦配置、CloudFlare 使用的配置。經(jīng)過(guò)測(cè)試，使用這兩份配置的 HTTPS 站點(diǎn)在啟用 HTTP/2 后都沒(méi)有問(wèn)題。

簡(jiǎn)單小結(jié)一下，對(duì)于能正常工作的 HTTPS 網(wǎng)站啟用 HTTP/2 后出現(xiàn)無(wú)法訪問(wèn)的問(wèn)題，請(qǐng)排查服務(wù)端這兩點(diǎn)配置：

1.是否啟用了 TLSv1.2；

2.是否正確配置了 CipherSuite。

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

本文來(lái)源于成都網(wǎng)站建設(shè)公司與成都網(wǎng)站設(shè)計(jì)制作公司-創(chuàng)新互聯(lián)成都公司！

文章名稱(chēng)：開(kāi)啟HTTP/2導(dǎo)致網(wǎng)站無(wú)法訪問(wèn)說(shuō)起
新聞來(lái)源：http://www.rwnh.cn/news39/310539.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)建站、定制開(kāi)發(fā)、網(wǎng)頁(yè)設(shè)計(jì)公司、網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)、網(wǎng)站導(dǎo)航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)