成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

從啟用 HTTP/2 導致網站無法訪問說起

作者：Jerry Qu
網絡 網絡管理
最近好幾個朋友在給網站開啟 HTTP/2 后，都遇到了無法訪問的問題。其中有的網站只是 Firefox 無法訪問，通過控制臺網絡面板可以看到請求被 Abort;有的網站不但 Firefox 無法訪問，連 Chrome 也會跳到錯誤頁，錯誤代碼是「ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY」。

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

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

首先，網站無法訪問有很多種可能，一般要從基本項開始檢查：

  • 網站 DNS 解析是否正常(可以通過 ping、nslookup、dig 等工具來排查);
  • 是否網絡不通(可以通過能否訪問 imququ.com 來排查 ^_^);
  • TCP 連接能否建立(可以通過 telnet 來排查，例如 telnet 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 就是好的。

實際上，Chrome 這個「ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY」錯誤代碼已經給出了兩個提示：

  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 中無法訪問：

 

  1. 在 Nginx 中配置以下 CipherSuite 并啟用 HTTP/2，在最新的 Firefox 中無法訪問： 
  2. ssl_ciphers ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-
  3. AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:AES128-GCM-
  4. 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)：

 

  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-
  2. RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:AES128-GCM-SHA256:AES128-SHA256:
  3. AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4' | column -t 

運行結果如下：

 

  1. 0xCC,0x13 - ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=ChaCha20-Poly1305 Mac=AEAD 
  2.  
  3. 0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD 
  4.  
  5. 0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 
  6.  
  7. 0xC0,0x14 - ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 
  8.  
  9. 0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD 
  10.  
  11. 0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 
  12.  
  13. 0xC0,0x13 - ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 
  14.  
  15. 0x00,0x9D - AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD 
  16.  
  17. 0x00,0x3D - AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 
  18.  
  19. 0x00,0x35 - AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 
  20.  
  21. 0x00,0x9C - AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD 
  22.  
  23. 0x00,0x3C - AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 
  24.  
  25. 0x00,0x2F - AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 
  26.  
  27. 0xC0,0x12 - ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1 
  28.  
  29. 0x00,0x0A - DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 

 

再通過 Wireshark 獲得 Firefox 在 Client Hello 中發送的 CipherSuite 列表，如下：

 

  1. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xC0,0x2B) 
  2.  
  3. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xC0,0x2F) 
  4.  
  5. TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xC0,0x0A) 
  6.  
  7. TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xC0,0x09) 
  8.  
  9. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xC0,0x13) 
  10.  
  11. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xC0,0x14) 
  12.  
  13. TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x00,0x33) 
  14.  
  15. TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x00,0x39) 
  16.  
  17. TLS_RSA_WITH_AES_128_CBC_SHA (0x00,0x2F) 
  18.  
  19. TLS_RSA_WITH_AES_256_CBC_SHA (0x00,0x35) 
  20.  
  21. TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x00,0x0A) 

 

CipherSuite 協商目的是找出兩端都支持的套件，也就是取出二者的交集：

 

  1. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xC0,0x2F) 
  2.  
  3. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xC0,0x13) 
  4.  
  5. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xC0,0x14) 
  6.  
  7. TLS_RSA_WITH_AES_128_CBC_SHA (0x00,0x2F) 
  8.  
  9. TLS_RSA_WITH_AES_256_CBC_SHA (0x00,0x35) 
  10.  
  11. TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x00,0x0A) 

 

乍一看選擇余地還挺大，但別忘了，HTTP/2 協議中還禁用了好幾百個。把這部分去掉后只剩下：

 

  1. 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 如下，大家可以自己分析下。

 

  1. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xC0,0x2B) 
  2.  
  3. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xC0,0x2F) 
  4.  
  5. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x00,0x9E) 
  6.  
  7. TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xCC,0x14) 
  8.  
  9. TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xCC,0x13) 
  10.  
  11. TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xC0,0x0A) 
  12.  
  13. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xC0,0x14) 
  14.  
  15. TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x00,0x39) 
  16.  
  17. TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xC0,0x09) 
  18.  
  19. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xC0,0x13) 
  20.  
  21. TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x00,0x33) 
  22.  
  23. TLS_RSA_WITH_AES_128_GCM_SHA256 (0x00,0x9C) 
  24.  
  25. TLS_RSA_WITH_AES_256_CBC_SHA (0x00,0x35) 
  26.  
  27. TLS_RSA_WITH_AES_128_CBC_SHA (0x00,0x2F) 
  28.  
  29. 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。

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

責任編輯：何妍 來源： Jerry Qu的小站
HTTP網絡協議
相關推薦

2009-01-16 09:06:00

2010-09-09 11:09:20

2015-12-15 15:27:37

NginxHTTP網絡協議

2022-01-07 11:31:01

勒索軟件攻擊網絡安全

2010-12-27 16:18:59

本地元數據庫

2011-02-25 09:17:08

CentOS

2014-03-13 11:39:10

YouTube宕機

2017-06-08 14:50:54

DNS緩存網頁

2009-07-10 14:28:38

2010-08-26 10:25:28

2011-08-23 09:10:25

路由路由策略

2009-03-30 15:11:10

2011-02-23 17:33:48

FileZilla

2011-08-18 09:18:10

宕機服務器

2012-01-23 23:57:12

SOPACBS黑客

2010-09-16 10:46:47

2024-06-28 09:25:51

2010-08-26 08:56:34

2011-05-05 10:31:44

DataTable

2012-03-19 21:06:52

Android
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板： 久久综合成人精品亚洲另类欧美 | 91九色在线观看 | 在线观看亚 | 久久精选 | 日本不卡在线观看 | 欧美精品在线观看 | 农夫在线精品视频免费观看 | 国产精品亚洲欧美日韩一区在线 | 久久成人免费视频 | 91精品国产综合久久精品 | 久久精品综合 | 天天操人人干 | 狠狠干五月天 | 亚洲一区综合 | 国产精品av久久久久久毛片 | 97超级碰碰 | 亚洲欧美网 | 亚洲一一在线 | 久草免费在线视频 | 日日干干 | 国产精品成av人在线视午夜片 | 亚洲成色777777在线观看影院 | 99精品网 | 欧美日韩亚洲一区 | 99热在线播放 | 黄色一级大片在线免费看产 | 国产一二三视频在线观看 | 精品一区久久 | 久久久www成人免费无遮挡大片 | 久久久久久女 | 99色综合| 成人黄色在线视频 | 国产欧美日韩综合精品一区二区 | 成人深夜福利在线观看 | 91精产国品一二三区 | 欧美xxxx网站 | 精品欧美黑人一区二区三区 | 成人在线免费观看 | 欧美一区二区三区在线 | 成人性生交a做片 | 国产精品乱码一区二区三区 |