我已成功配置 Windows Server 2008 R2 和 IIS 7.5 服務於我的 Asp.Net 4 應用程序。它使用hass.de 部落格文章中的資訊設置為前向保密。

我仍然有使用低級瀏覽器的訪問者，主要是帶有僅支持 SSL v3.0 的 Internet Explorer 8 的 Windows 7。

當這些人訪問我的網站時，他們看到的只是Internet Explorer cannot display the webpage. 伺服器上沒有任何跡象表明訪問者的請求失敗，例如沒有 IIS 日誌記錄事件、沒有 eventvwr.msc 事件 ID，或任何其他顯示訪問者請求無法被接受的事件/跟踪/調試。

執行Network Monitor，可以看到使用者與伺服器通信時，流量中只有4個數據包：

1. 客戶：SYN
2. 伺服器：SYN, ACK
3. 客戶：SSL 'Client Hello'
4. 伺服器：RST, ACK反對“客戶你好”

通信停止，客戶端瀏覽器顯示Internet Explorer cannot display the webpage。

我在 BrowserStack 中重現了訪問者的場景：

**問題：**有沒有辦法配置 IIS 以重定向瀏覽器請求，該請求不支持前向保密，因此使用者不會收到Internet Explorer cannot display the webpage錯誤消息？

有幾件事要弄清楚，首先。

背景

我們稍微混合了兩個不同的概念：協議和密碼套件。SSLv3 是協議，前向保密是協商密碼套件的一個特徵。選擇哪些密碼套件取決於客戶端、伺服器和協商的協議。

這意味著您不能依賴協議的版本來決定瀏覽器是否支持前向保密（這可能會隨著 TLS 1.3 改變）。SSLv3（至少作為規範）確實支持一些前向保密密碼套件，例如SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA（儘管在實踐中我沒有看到支持該密碼套件的瀏覽器）。這同樣意味著 TLS 版本不強制要求使用前向保密。

Internet Explorer 是一個有趣的案例，因為它是唯一支持密碼取決於瀏覽器版本和 Windows 版本的主要瀏覽器。這是因為 Internet Explorer 將所有 HTTPS 協商和處理都交給了名為SChannel. 為了讓 Internet Explorer 支持給定的協議和密碼套件，SChannel 需要首先支持它。這使得說支持哪些密碼套件和協議變得有點複雜。

有一個版本的 Internet Explorer 支持 SSLv3，沒有其他版本，那就是 Internet Explorer 6。它仍然是唯一一個有少量使用但不支持 TLS 1.0 的瀏覽器（這並不完全正確；IE6 確實支持它，它是只是預設情況下未啟用）。因此，通過顯示錯誤頁面的麻煩，您唯一的目標瀏覽器是 Internet Explorer 6。我想其他瀏覽器可以禁用對所有版本的 TLS 的支持，只選擇 SSLv3，但這意味著大部分啟用 HTTPS 的網站將無法為它們工作，因為許多網站已經完全禁用了對 SSLv3 的支持。實際上，我認為您不會遇到許多僅支持 SSLv3 而不是 IE 6 的瀏覽器。Windows XP 上的 IE 8 預設啟用 TLS 1.0，Windows Vista 或更高版本上的任何 IE 版本都支持至少 TLS 1.0。Windows 8 和 Windows 7 上的 Internet Explorer 11 支持（截至撰寫時）最新的 TLS 1.2。

顯示“抱歉，沒有 SSLv3！” 頁面：會出現什麼問題？

更接近您的問題，您關心的是向瀏覽器想要與 SSLv3 連接的使用者顯示一個頁面。這有好處也有壞處。首先，請注意 SSLv3 存在一個名為POODLE的問題。POODLE 的發現讓許多網站完全關閉了 SSLv3 支持。

這導致了先有雞還是先有蛋的問題。如果您要根據協商的協議版本重定向使用者，您的 Web 伺服器首先需要支持 SSLv3 以檢測它的存在並提供重定向。但是，這樣做可能會使這些客戶面臨不必要的風險。如果伺服器必須接受 SSLv3 連接以向使用者顯示不允許使用 SSLv3 的頁面，則主動攻擊者可以利用它作為利用 SSLv3 弱點的機會。例如，假設客戶端使用 TLS 1.0 通過 HTTPS 對您的網站進行身份驗證。IE 不支持TLS_FALLBACK_SCSV，主動攻擊者將瀏覽器強制降為 SSLv3。如果您的站點使用 cookie 進行身份驗證，則攻擊者現在已強制瀏覽器使用 SSLv3（這將為您的錯誤重定向提供服務）但是它可能會洩露身份驗證 cookie。請記住，一旦使用者獲得了身份驗證 cookie，瀏覽器就會將這些 cookie 與每個請求一起發送。竊取身份驗證 cookie 是一件大事，在這種情況下使用 POODLE 完全有可能。因此，即使您只是嘗試一些簡單的錯誤頁面，也存在與支持 SSLv3 相關的風險。

IIS 無法自行執行此操作

所以，對於你的實際問題。不，Internet 資訊服務本身無法重定向基於 SSL/TLS 版本或密碼套件的請求。可能有一個第三方模組可以做到這一點，但我不知道有一個。不過，您有幾個選擇。

可以在負載均衡器上修復

您可以將連接解除安裝到支持基於 SSLv3 存在的重定向的反向代理 - 我不知道基於實際密碼套件執行此操作的方法。HAProxy 是我所知道的——可能還有其他我不熟悉的。我不會詳細介紹，但使用 HAProxy，您可以根據 SSL 版本分配 ACL，如下所示：

acl sslv3 ssl_fc_protocol SSLv3

擁有 ACL 後，您可以將它們發送到特定的後端，或根據需要進行處理。

可以用自己的 IIS 模組修復

其他選項可能是查找或開發您自己的 IIS 模組來執行此操作。恕我直言，IIS 對配置和支持 SSL 沒有出色的支持。就個人而言，我會將 SSL 解除安裝到反向代理上，但我知道這並不適合所有人。

只需禁用低於 TLS 1.0 的協議支持即可修復

您的第三個選項是僅支持前向保密密碼套件並且至少支持 TLS 1.0。使用AES128+EECDH:AES128+EDH包含 TLSv1、TLSv1.1 和 TLSv1.2 的密碼套件將獲得對大多數瀏覽器的支持。唯一會被冷落的瀏覽器是 Windows XP 上的任何 Internet Explorer 版本，因為 Windows XP 不支持任何支持前向保密的合理密碼套件。據我所知，Windows XP 僅支持帶有 DSS 的 DHE，這是您絕對不想費心支持的。

我的方式：禁用 SSL 協議支持

後者是我採用的解決方案。支持已棄用的協議和密碼套件會帶來風險——即使它們只是為了顯示錯誤頁面。

引用自：https://serverfault.com/questions/681075