我在事件日志中收到 ID 号为 36888 和 36874 的错误。错误状态分别为“生成了以下致命警报：40。内部错误状态为 1205。”和“从远程客户端应用程序接收到 SSL 3.0 连接请求，但客户端应用程序支持的任何密码套件均不受服务器支持。SSL 连接请求失败”。我想在不禁用 schannel 日志记录的情况下找出导致此问题的原因。操作系统运行的是 Windows Server 2008 R2 和 Outlook Web Access。服务器上的 IE 设置已选中 TLS 1.0、TLS 1.1、TLS 1.2、SSL 3.0，而未选中 SSL 2.0。我应该如何调查此问题？使用 wireshark 捕获并从那里开始，还是完全使用其他方法？
答案1
这种情况总是可以从外部强制发生的；连接并发送一条ClientHello仅列出垃圾值作为“支持的密码套件”的消息就足够了。使用Wireshark或者一些等效的监控工具微软的网络监视器确实是可行的方法：
- 在 IIS 上激活 HTTP 级别日志记录。
- 启动监视工具。
- 等待事件再次出现。
- 查看
ClientHello事件触发时收到的消息。
这些ClientHello消息必然是未加密的。因此，您可以查看已公布的密码套件列表，并将其与您的服务器配置进行匹配。网络监视工具还会向您显示客户端 IP 地址。如果该消息是多连接尝试的一部分（例如，客户端首先尝试使用某些参数进行连接，然后再次尝试使用其他参数），那么您可能会看到来自同一客户端的成功连接，此时 IIS 中的 HTTP 级别日志记录将告诉您客户端声称使用什么软件（这是 HTTP 标头的一部分）。
一个合理的解释是探测：如果有人想弄清楚你的服务器支持哪些密码套件，那么它会使用越来越少的支持密码套件列表进行一些连接尝试；这必须最终会得到像你展示的那样的事件。实现这一点的探测工具是提供在线服务；其他人可以被下载。
任何面向互联网的服务器都可能偶尔被探测；这就是现状（道德上令人遗憾，但近期不太可能改变）。最好的办法可能是简单地从警报机制中过滤掉这些事件，以便完全忽略它们。无论如何，它们大多是无害的。