如何設定 IIS 7.5 SSL \ TLS 以與 iOS 9 ATS 搭配使用

Question

問題：由於 iOS 9 現在使用 ATS，我們的行動應用程式無法再與我們的網路服務建立安全連線。

背景： iOS 9 引入了應用程式傳輸安全性

伺服器設定：Windows Server 2008 R2 SP1 (VM) IIS 7.5，來自 digicert 的 SSL 憑證。 Windows 防火牆關閉。

金鑰 RSA 2048 位元 (e 65537)

頒發者 DigiCert SHA2 安全伺服器 CA

簽章演算法 SHA512withRSA

這些是應用程式傳輸安全要求：

伺服器必須至少支援傳輸層安全性 (TLS) 協定版本 1.2。連線密碼僅限於提供前向保密的密碼（請參閱下面的密碼清單。）必須使用SHA256 或更好的簽章雜湊演算法（使用2048 位元或更高的RSA 金鑰或256 位元或更高的橢圓曲線）對憑證進行簽署(ECC) 金鑰。無效證書會導致硬故障並且無法連線。這些是可接受的密碼：

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_SHA_SHA384 TLS_EC_ECDSA_WITH_AES_256_SHA_SHA384 TLS_DHE_ECDS_ _128_ CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256_F _AES_128_CBC 256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

已經嘗試過的：

1. 在行動應用程式中添加例外以允許我們的網域正常工作，但我不想採用這種不安全的方法，我想修復我們的 SSL。
2. 用過的IIS 加密使用“最佳實踐”，嘗試“pci”和自訂設定。甚至嘗試將加密套件修改為上面的列表，然後重新排序。每次嘗試後，伺服器都會重新啟動，並且SSL實驗室已運行（清除快取後）。我成功地從 F 評級升至 A 級，甚至 A 級，但這只會導致 iOS 8 和 9 無法建立安全連線。 （NSURLErrorDomain 代碼=-1200 和 _kCFStreamErrorCodeKey=-9806）
3. 還原虛擬機器並嘗試使用 powershell 腳本設定 IIS 以實現 SSL 完美前向保密和 TLS 1.2我甚至進行了第二次嘗試，將電源腳本中的密碼編輯為所需內容的最小清單。

結果：始終相似，評級為 A 或 A-。 iOS8和iOS9無法協商安全連線。握手模擬會導致 Safari 和 iOS 產品出現「協定或密碼套件不符」。

更新與 Apple 支援人員合作後，我們進行了一些資料包追蹤擷取：

$ tcpdump -n -r trace.pcap
reading from file trace.pcap, link-type EN10MB (Ethernet)
client > server [S], seq 1750839998, win 65535, length 0
server > client [S.], seq 2461151276, ack 1750839999, win 8192, length 0
client > server [.], ack 1, win 4104, length 0
client > server [P.], seq 1:175, ack 1, win 4104, length 174
server > client [R.], seq 1, ack 175, win 0, length 0

前三個封包是經典的 SYN - SYN-ACK - ACK 三向握手，用於建立 TCP 連線。第四個資料包是 iOS 會向您的伺服器發送 TLS Client Hello 訊息，這是透過 TCP 連線建立 TLS 連線的第一步。我把這則訊息拆開來看，看起來很合理。在第五個資料包中，伺服器簡單地斷開連接（透過發送 RST）。

有人知道為什麼 IIS 7.5 會執行 RST？

Answer 1

這個問題很老了，但是搜尋的時候就會發現。我花了一些時間來尋找相同問題的解決方案。因此我決定寫下答案與其他人分享我的結果。

簡短回答：您不應該使用 IIS Crypto 來指定密碼套件的順序。我建議您按一下「預設」按鈕刪除先前設定的順序，然後使用群組原則（「電腦設定」\「管理範本」\「網路」\「SSL 設定設定」）透過本機原則設定密碼套件。

錯誤「協定或密碼套件不符」的原因可能是以下之一：

• 你的伺服器支援一些“壞密碼套件”
• 您的伺服器不支援某些密碼套件，必須支援符合 TLS 規範的密碼套件。
• 你的伺服器支援 HTTP/2 並且它有一些來自黑名單 多於清單中未列出的其他協議。通常，更改密碼套件的順序就足以解決問題。

不同系統上的確切黑名單可能有所不同。你可以在網路上找到一些黑名單。例如，附錄ARFC 7540（超文本傳輸協定版本 2 (HTTP/2)）包含一個清單。密碼套件適用TLS_RSA_WITH_AES_128_CBC_SHA於 TLS 1.2（請參閱這裡）和TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA2561.3（請參閱這裡）。唯一TLS_ECDHE_ECDSA_*重要的是您使用帶有橢圓曲線的憑證。其他非常好的密碼套件TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256尚未由微軟實現。此外，您可以考慮添加至少TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA支援來自舊系統的連接，並TLS_RSA_WITH_AES_128_CBC_SHA支援非常舊的系統（Android 2.3.7、Java 6u45、OpenSSL 0.9.8y），並且TLS_RSA_WITH_3DES_EDE_CBC_SHA僅當您需要支援 IE 8 / XP 時。因此您可以使用今天，例如

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

停用 TLS 1.0、TLS 1.1為了有更好的安全性或只是

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

如果您需要良好的安全性和最佳性能。

您可以設定以下簡短的密碼套件來解決您的問題：

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

下面我提供了 Windows 10 上的設定範例。具有 RSA 2048 密鑰和 Let's Encrypt 的免費 SSL 證書，獲得 Qualys SSL Labs 的 A+ 評級。

我禁用了DES 56/56、RC2 128/128、RC2 40/128、RC2 56/128、RC4 128/128、RC4 40/128、RC4 56/128、RC4 64/128、三重DES 168/168、ULL 、 MD5、多重協定統一Hello、PCT 1.0、SSL 2.0、SSL 3.0 和 TLS 1.0/1.1手動在登錄中（看KB245030）。我禁用 TLS 1.0 和 TLS 1.1 協定只是因為到目前為止 IIS 中無法阻止 TLS_FALLBACK_SCSV（降級攻擊），這使得不可能獲得 A+ 評級www.ssllabs.com。我認為這是一個缺點，但 TLS 1.2 目前支援範圍非常廣泛。順便說一句，您可以使用DisabledByDefault: 1, 但Enabled: 1適用於 TLS 1.0 和 TLS 1.1。如果您在電腦上執行 SQL Server 2008/2012，這可能會很有幫助。 Web 伺服器不會使用 TLS 1.0 和 TLS 1.1，但 SQL Server 會使用。

最重要的一步是密碼套件的配置，這花了我很多時間，也是您的主要問題。我用它做了gpedit.msc。我選擇“電腦配置”\“管理模板”\“網路”\“SSL 配置設定”並將“SSL 密碼套件順序”值配置為以下內容

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

上述順序可能不是最佳的，而且我不確定 IIS 7.5 是否支援上述所有協定（我使用 Windows 10 中的 IIS 10.0）。不過，我確信您的問題與密碼套件清單有關，因為我在使用密碼套件清單進行實驗時遇到了與您描述的完全相同的問題。

無論如何，在群組原則中配置上述設定後，重新啟動計算機（gpupdate /force /target:computer在我的測試中還不夠）我得到了 A+ 評級以及以下“握手模擬”部分的測試結果列表：

可以看到 iOS 已成功支援以下用戶端：

Safari 6 / iOS 6.0.1
Safari 7 / iOS 7.1
Safari 8 / iOS 8.4
Safari 9 / iOS 9

不支援 TLS 1.2 的客戶端現在對我來說似乎不再那麼重要，我認為上述配置是舊版客戶端的支援和安全協定的使用之間的良好折衷。

Answer 2

如果您的 IIS 加密映像是最新的，請保持設定不變，但啟用 SHA、Diffie-Hellman 和 PKCS。這將為您提供 A 評級，但允許 iOS 8 及更低版本進行連線。

Answer 3

我為此苦苦掙扎了幾天。特別是，我使用 Xamarin Forms PCL 從 iOS 應用程式進行連接，以透過 OAuth2 Bearer Token 驗證連接到 ASP.NET Web Api 2 Rest 服務。

最終對我有用的是使用 IIS Crypto 的最佳實踐。然後編輯為密碼套件順序設定的登錄項目：

KEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002\Function

我取得了成功，具有以下價值：

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521、TLS_RSA_WITH_AES_256_CBC_SHA384_P521、TLS_ECDHE_RSA_WILS_ _AES_256_CBC 8_CBC_SHA256_P521,TLS_EC _CBC_SHA_P384、TLS_ECDHE_RSA_WITH_AES_128 _CBC_SHA_P256、TLS_RSA_WITH_AES_256_GCM_SHA384、TLS_RSA_WITH_AES_128_GCM_GCM_SHA384、TLS_RSA_WITH_AES_128_GCM_GCM_SHA384、TLS_RSA_WITH_AES_128_GCM_GCM_SHA384、TLS_RSA_WITH_AES_128_GCM_GCM_SHA384、TLS_RSA_WITH_AES_128_GCM_SHA256,_RSA CBC_SHA、TLS_RSA_WITH_AES_128_CBC_SHA256、TLS_RSA_WITH_AES_12 8_CBC_SHA、TLS_RSA_WITH_3DES_EDE_CBC_SHA、TLS_ECDHE_ECDSA_WITH_AES_256_M_SHA、TLS_ECDHE_ECDSA_WITH_AES_256_M_SHA38 384_P384 、TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521、TLS_ECDHE _ECDSA_WITH_AES_128_GCM_SHA256_P384，TLS_ECDHE _ECDSA_WITH_AES_128_GCM_SHA256_P384，2TLS_ECDHE_ECDSA_WITH_D1256_P38442 TLS_ECDHE_ECDSA_WITH_LEC_128 56_CBC_SHA384_P521、TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384、TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521 ,TLS_ECDHE_EC_AES_256_EC_SHA_P521 ,TLS_ECDHE_EC_WIS. _AES_256_CBC_SHA_P256,TLS_EC DHE_ECDSA_WITH_AES_128_CBC_SHA256_P521,TLS_ECDHE_ECDSA_WITH_AES_128_WICBC_SHA256_P384,TLS_DEC_WIHE26_EC_26_EC_P384,TLS_EC_ _ECDSA_WITH_AES_128_CBC_SHA_P521、TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384、TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256、TLS_D8DS_WITH_AES_128_CBC_SHA_P256、TLS_F8_RSA ES_128_GCM_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_256_SHA_SHA,TLS_DHE_DSS_WITH_AES_128_1_SHA25. WITH_3DES_EDE_CBC_SHA、TLS_RSA_WITH_RC4_128_SHA、 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384、TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256、TLS_ECDHE_ECDSA_WITH_AES_256_SHA_SHA384、B丈夫_ECDS A_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_RC4_128_MD5,TLS_RSA_WITH_DES_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

最後一個是透過使用 Charles Proxy 找到的，它自動協商 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。導致我出現這種情況的原因是，在 Charles Proxy 開啟（安裝了模擬器憑證）的情況下連線成功，但否則失敗。添加它在談判中使用的套件就達到了目的。看來（？）代理正在與我的其餘服務重新協商，其中的內容受我的伺服器支持，但不支援 iOS 用戶端。

請注意，許多密碼套件是從 ssllabs 的各種 iOS/OSX 裝置首選套件規格中獲得的。 上面的值應該與除 XP 上的 IE 6 之外的所有內容握手根據 ssllabs 的評級，具有 A 級。