開啟HTTP/2導(dǎo)致網(wǎng)站無法訪問說起
2023-12-27 分類： 網(wǎng)站建設(shè)
最近好幾個朋友在給網(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)絡(luò)不通（可以通過能否訪問 imququ.com 來排查 ^_^）；
網(wǎng)站 DNS 解析是否正常（可以通過 ping、nslookup、dig 等工具來排查）；
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 報文前，還得先跟服務(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)給出了兩個提示：
1.與 HTTP/2 有關(guān)。SPDY 是 HTTP/2 的前身，這個錯誤碼應(yīng)該是從 SPDY 時代沿用下來的；
2.與 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。至此可以肯定，之所以出現(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 中無法訪問：
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)置了對它的支持。
先來看看上述配置指定的 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ā)郵件討論。
本文來源于成都網(wǎng)站建設(shè)公司與成都網(wǎng)站設(shè)計(jì)制作公司-創(chuàng)新互聯(lián)成都公司！
這個問題比較有趣，本文除了告訴大家如何解決它之外，還會幫助大家弄清問題的來龍去脈。如果你只關(guān)心結(jié)論，直接看最后的小結(jié)即可。
首先，網(wǎng)站無法訪問有很多種可能，一般要從基本項(xiàng)開始檢查：
是否網(wǎng)絡(luò)不通（可以通過能否訪問 imququ.com 來排查 ^_^）；
網(wǎng)站 DNS 解析是否正常（可以通過 ping、nslookup、dig 等工具來排查）；
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 報文前，還得先跟服務(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)給出了兩個提示：
1.與 HTTP/2 有關(guān)。SPDY 是 HTTP/2 的前身，這個錯誤碼應(yīng)該是從 SPDY 時代沿用下來的；
2.與 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。至此可以肯定，之所以出現(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 中無法訪問：
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)置了對它的支持。
先來看看上述配置指定的 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ā)郵件討論。
本文來源于成都網(wǎng)站建設(shè)公司與成都網(wǎng)站設(shè)計(jì)制作公司-創(chuàng)新互聯(lián)成都公司！
文章名稱：開啟HTTP/2導(dǎo)致網(wǎng)站無法訪問說起
新聞來源：http://www.muchs.cn/news39/310539.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)建站、定制開發(fā)、網(wǎng)頁設(shè)計(jì)公司、網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)、網(wǎng)站導(dǎo)航
聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容
- 成都軟件開發(fā)的開發(fā)流程有哪些呢? 2023-12-27
- 如何在網(wǎng)站設(shè)計(jì)中使用視覺上驚艷的網(wǎng)頁？ 2023-12-27
- 網(wǎng)站推廣得怎么推廣網(wǎng)站才能為企業(yè)帶來用戶？ 2023-12-27
- 網(wǎng)站模板代碼開發(fā)有哪些基礎(chǔ)？制作網(wǎng)頁代碼大全！ 2023-12-27
- 成都競價托管：提高轉(zhuǎn)化率的5個步驟 2023-12-27
- 如何為您的服務(wù)器選擇帶寬 2023-12-27
- 美國Linux服務(wù)器SSL證書辦理以及安裝的方法 2023-12-26
- 多服務(wù)器環(huán)境的好處是什么？ 2023-12-27
- 成都網(wǎng)站建設(shè)的步驟是怎樣的？ 2023-12-27
- 制作網(wǎng)站的教程有沒有？怎樣定制制作網(wǎng)站？(如何制作網(wǎng)站教程) 2023-12-27
- 成都建立網(wǎng)站需要哪些條件和流程？ 2023-12-27
- 高端網(wǎng)頁定制開發(fā)推廣好處是什么 2023-12-27
- 網(wǎng)站建設(shè)中如何設(shè)計(jì)出一個高端、大氣、簡約的網(wǎng)站？(自己如何做網(wǎng)站建設(shè)) 2023-12-26
- 聽聽成都app開發(fā)說4G才開始“4G+”又來了運(yùn)營商玩什么花樣？ 2023-12-26
- 網(wǎng)站優(yōu)化之站長應(yīng)該如何找到優(yōu)質(zhì)的外鏈？ 2023-12-26
- 百度網(wǎng)絡(luò)推廣有哪些優(yōu)勢？ 2023-12-26
- 成都網(wǎng)站制作在全國發(fā)展給力 2023-12-26
- 排版與布局在網(wǎng)頁中的應(yīng)用 2023-12-26
- 怎樣可以快速的建設(shè)自己的網(wǎng)站？帶你一起來看看(怎樣可以快速建多人群) 2023-12-26