【茶包射手筆記】Chrome、Python 可以但 IE11、.NET 程式無法連線的 TLS 1.2 網站

讀者小螺絲分享了一個沒遇過的 TLS 1.2 案例。從一台 Winows 2012R2 主機要連線某個外部網站，實測使用 IE 及 .NET Client 無法連線，訊息為「基礎連接已關閉: 傳送時發生未預期的錯誤。 ---> System.IO.IOException: 驗證失敗，因為遠端群體已經關閉傳輸資料流。 The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Authentication failed because the remote party has closed the transport stream」之類的 TLS 1.2 支援問題，但若改用 Chrome/Python/Postman 則可正常連線。

整理線索如下：(蒐集的資訊蠻專業完整的，有利於分析)

• 使用 IE11、.NET 程式 (使用 WebClient) 無法連線，同樣的 .NET 程式在 Windows 10 執行則正常
• Windows 2012R2 主機有做 Windows Update，依據舊文 Windows 停用 TLS 1.0 之配套作業整理，Windows 2012 R2 只要裝妥必要更新，即使 .NET 3.5 都能支援 TLS 1.2。
• 測試改用其他 Client：cURL 無法連線，但 Chrome、Python、Postman 可以
• 由 Postman 及 Chrome 的安全連線資訊得知問題網站使用 ECDHE_RSA_AES128_GCM_SHA256 Cipher Suite (金鑰交換演算法、加密演算法及雜湊演算法的組合)
  
  延伸閱讀：什麼是 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256? 你看懂了嗎? by 恆毅
• 依據官方文件，Windows 2012R2 所支援的 TLS Cipher Suite 比照 Windows 8.1，不包含 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ，Windows 10 也要到 v1511 才支援。

在我先前的認知，Web 主機通常會支援很多種 TLS Cipher Suite，客戶端會在交握階段協商找到兩邊都支援的演算法組合。一般的網站 SSL 憑證支援的 Sipher Suite 常多達到十幾種，以求支援大部分的瀏覽器，畢竟要做生意當然不希望把客戶擋在門外。

要檢測網站 TLS 憑證安全度與支援的 Cipher Suite，可使用 Qualys SSL Labs 的 SSL Server Test ，以 Facebook 網站為例，支援的 Cipher Suite 如下圖這麼多，TLS 1.0/1.1 也還沒關：(SSL Labs 只能檢測放在 Internet 上的站台，要測試內部站台或非網站，可以考慮用這篇提到的 nmap + ssl-enum-ciphers)

重頭戲來了，這個 Windows 2012R2 IE 及 .NET 程式連不上的網站，到底支援哪些 Cipher Suite 呢？

只開 TLS 1.2，而且只支援兩種 Cipher Suite，而它們都不在 Windows 2012R2 支援範圍，下方的 Handshake Simulation 也顯示不支援 IE11 / Win8.1 客戶端。Chrome、Python、Postman 應是使用 OpenSSL 或其他 TLS 連線程式庫，因而能成功連線。這個案例遇到的現象，也算有了合理解釋。

為什麼網站只開放兩種 Cipher Suite 呢？

我猜這個 A+ 是原因。Cipher Suite 支援項目愈多，難免摻入安全強度較差的選項，可能讓整體安全等級下滑，到時得跟資安稽查單位解釋為什麼沒做到 A+，不如... 嘿。

不過有點好奇，支援較弱的 Cipher Suite 就一定拿不到 A+ 嗎？我還真的查到反例：

不愧是 FBI 呀! 關於 SSL Labs 評分機制的奧祕，又是另一門有待研究的學問了。

感謝小螺絲分享的案例，讓我對 TLS 的認識再深入幾釐米。

A case of .NET client and IE on Windows 2012R2 failed to connect a TLS 1.2 website. This article demostrats how to use SSL Labs tool to check and find the cipher suite issue.