C#請求HTTPS地址的故障分析和TLS知識點總結

背景介紹

近期收到同事反饋,在C#程序中通過HTTPClient請求一個HTTPS的地址時,在本地開發環境和測試環境均能正常執行,而部署到生產環境後發生異常且穩定復現,異常提示爲:【請求被中止: 未能創建 SSL/TLS 安全通道 】,而且在生產環境用瀏覽器訪問是沒問題的。

目標站點和運行環境介紹

  • 目標站點SiteA(同事對接的站點):jc.ebopark.com
  • 目標站點SiteB(對比站點):www.howsmyssl.com
  • 生產環境服務器MA1:Windows Server 2016 Datacenter+.NET Framework 4.8,鏡像來自Azure
  • 測試環境服務器T1:Windows Server 2016 Datacenter+.NET Framework 4.8,鏡像來自Azure
  • 本地臨時VMware虛擬機VM1:Windows Server 2016 Datacenter+.NET Framework 4.8,鏡像來自微軟官網

初步分析

自然的,根據異常信息先進行一圈Google(不用百度),基本都是在說ServicePointManager.SecurityProtocol的賦值,但是本次的程序中已經配置了全部協議。在瞭解了大概背景之後,基本斷定該故障與源碼本身的關係不大,仔細檢查源碼後也確實沒有問題。大家也能看得出,很明顯的環境不同導致的故障,那麼宿主環境的差異就是我們優先要排查分析的線索。

這裏要引入HTTPS的一些知識點

1、關於HTTP、HTTPS、TLS的關係:HTTPS連接是由HTTP協議與TLS協議共同完成。

2、建立HTTPS連接不僅需要Client與Server雙方的TLS協議版本號兼容,還需要Cipher Suites(密碼套件)兼容。關於什麼是Cipher Suites可以自行查閱資料,本文不詳細展開說明。Cipher Suites的樣子如圖所示:

進一步驗證

有了以上理論支撐,下面就開始對本次案例的站點和運行環境進行一一分析;

首先,通過在線工具驗證目標站點SiteA自身的HTTPS連接功能是否OK:

截圖報告顯示SiteA支持TLS1.2、TLS1.3協議,同時也可以看到對應的密碼套件。說明該站點自身配置沒問題,這也符合同事的測試結果。

根據前面提到的知識點,下一步就需要判斷連接的Client端(即C#應用)所支持的協議和密碼套件。先看在程序中配置的是支持TLS全協議:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 |
                                                        SecurityProtocolType.Tls |
                                                        SecurityProtocolType.Tls11 |
                                                        SecurityProtocolType.Tls12 |
                                                        (SecurityProtocolType) 12288;

其次查看運行時部署的.NET Framework 4.8對TLS的兼容情況,如下圖所示,環境對TLS1.2、TLS1.3均支持。

現在TLS協議看起來是兼容的,那麼該如何查看C#應用所使用的密碼套件?這裏用到一個工具:IISCrypto.exe

生產環境服務器MA1的密碼套件如下圖所示。經過仔細對比,該OS沒有與目標站點SiteA匹配的密碼套件,因此無法建立連接,符合實際情況。

測試環境服務器T1的密碼套件如下圖所示。該OS中有2組和目標站點SiteA的TLS1.2密碼套件匹配,因此可以建立鏈接,符合實際情況。

本地臨時VMware虛擬機VM1的密碼套件如下圖所示,該OS中有多組和目標站點SiteA的TLS1.2密碼套件匹配,因此可以建立鏈接,符合實際情況。

經過上述對比後,基本可以判定是由於生產環境的服務器密碼套件與目標站點不匹配導致。

解決方案比較簡單,使用IISCrypt工具把缺少的密碼套件勾選,並擇機重啓服務器生效即可。

延伸1:如何創建TLS1.3協議的連接?

根據前面對幾臺服務器的密碼套件的分析,兼容的密碼套件都是最多是TLS1.2版本的,那是否真可以創建TLS1.3的連接呢?所幸我本地開發環境比較新,是Windows11,經過查看密碼套件可以兼容TLS1.3:

使用工具在只選擇TLS1.3協議的情況下,驗證是可以成功請求的:

延申2:Edge瀏覽器所支持的密碼套件自帶的,獨立於Windows。

下圖是生產環境服務器MA1上的Edge瀏覽器的密碼套件支持情況。

通過該瀏覽器直接請求目標站點SiteA,不僅可以請求成功而且還是走的TLS1.3協議。

總結

本文針對實際開發中遇到怪異現象,結合HTTPS的理論知識,透徹的分析了故障原因並最終解決。本文中還提到了幾個實用的工具,可以更方便的查看相關細節。最後針對生產服務器鏡像默認的密碼套件問題,後續會繼續與運維同事反饋並更新。

參考資料:

  • 查看TLS在線工具:https://myssl.com/ssl.html
  • IISCrypto官網:https://www.nartac.com/Products/IISCrypto/
  • .NET Framework 中的傳輸層安全性 (TLS) 最佳做法:https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls
  • 查看當前連接的tls信息-API版:https://www.howsmyssl.com/a/check

附:蘋果推送服務API的TLS信息

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章