我已成功配置了 Windows Server 2008 R2 和 IIS 7.5，为我的 Asp.Net 4 应用程序提供服务。它使用以下信息进行前向保密设置摘自 hass.de 博客文章。
我仍然有一些使用低版本浏览器的访问者，主要是 Windows 7 和仅支持 SSL v3.0 的 Internet Explorer 8。
当这些人访问我的网站时，他们看到的只是Internet Explorer cannot display the webpage。服务器上没有任何迹象表明访问者的请求失败，例如没有 IIS 日志记录事件、没有 eventvwr.msc 事件 ID，或任何其他事件/跟踪/调试表明访问者的请求无法被接受。
运行后Network Monitor，我可以看到用户与服务器通信时流量只有 4 个数据包：
- 客户：
SYN - 服务器：
SYN, ACK - 客户：
SSL 'Client Hello' - 服务器：
RST, ACK针对‘客户端问候’
通信停止，客户端浏览器显示Internet Explorer cannot display the webpage。
我在 BrowserStack 中重现了访问者的场景：
问题：有没有办法配置 IIS 来重定向无法支持前向保密的浏览器请求，以便用户不会收到Internet Explorer cannot display the webpage错误消息？
答案1
首先，要澄清一些事情。
背景
我们稍微混淆了两个不同的概念：协议和密码套件。SSLv3 是协议，而前向保密是协商密码套件的特性。选择哪种密码套件取决于客户端、服务器和协商的协议。
这意味着您不能依赖协议的版本来决定浏览器是否支持前向保密（这可能会随着 TLS 1.3 而改变）。SSLv3（至少作为规范）确实支持一些前向保密密码套件，例如SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA（尽管在实践中我没有看到支持该密码套件的浏览器）。这同样意味着 TLS 版本不强制使用前向保密。
Internet Explorer 是一个有趣的例子，因为它是唯一一款支持的密码取决于浏览器版本的主流浏览器和Windows 的版本。这是因为 Internet Explorer 将所有 HTTPS 协商和处理都交给了 Windows 的一个名为 的组件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的发现让很多网站彻底关闭了SSLv3支持。
这导致了先有鸡还是先有蛋的问题。如果您要根据协商的协议版本重定向用户，您的 Web 服务器首先需要支持 SSLv3，以便检测其存在并提供重定向。但是这样做可能会让这些客户端面临不必要的风险。如果服务器必须接受 SSLv3 连接才能向用户显示不允许使用 SSLv3 的页面，那么主动攻击者可以利用这一点作为利用 SSLv3 弱点的机会。例如，假设客户端使用 TLS 1.0 通过 HTTPS 向您的网站进行身份验证。IE 不支持TLS_FALLBACK_SCSV，主动攻击者会强制浏览器降级到 SSLv3。如果您的网站使用 cookie 进行身份验证，那么攻击者现在已经强制浏览器降级到 SSLv3（这将为您提供错误重定向）但它可以泄露身份验证 cookie。请记住，一旦用户拥有了身份验证 cookie，浏览器就会随每个请求发送这些 cookie。窃取身份验证 cookie 是一件大事，在这种情况下使用 POODLE 完全有可能。因此，即使您只是尝试访问一些简单的错误页面，支持 SSLv3 也存在风险。
IIS 无法独自完成此任务
那么，回到你的实际问题。不，互联网信息服务本身无法根据 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+EDHTLSv1、TLSv1.1 和 TLSv1.2 的密码套件将获得以下支持最多浏览器。唯一被冷落的浏览器是 Windows XP 上的任何 Internet Explorer 版本，因为 Windows XP 不支持任何支持前向保密的合理密码套件。据我所知，Windows XP 仅支持带有 DSS 的 DHE，这是您绝对不想费心支持的。
我的方法：禁用 SSL 协议支持
我选择后者。支持弃用的协议和密码套件会带来风险 - 即使它们只是为了显示错误页面。