我有一个网站(来自客户端)正在我的 Win 2008 R2 标准服务器上访问 WCF 服务。 WCF 服务托管在 IIS 7.5 上。连接是 HTTPS 加密的。我无权访问客户端的服务器。
为了调试问题，我需要检查客户端发送的请求。我正在使用 WireShark 1.10.3。为了这。如果我先运行 WireShark 并且 2 个服务器使用完全握手连接，我就能获得解密信息。如果服务器使用的是缩写握手，则 WireShark 无法解密。
Abbreviated Handshake 采用了一种称为 SSL session 重用的技术，其中两台服务器将加密/解密信息存储在缓存中。这消除了完全握手所需的步骤，并为将来的请求节省了 CPU。我读到此缓存的默认 TTL 为 10 小时，但我还没有找到设置它的位置。当任一服务器缓存中都没有信息时，TLS 按规范进行完全握手。完全握手后，它会自动缓存信息，以便随后进行简短握手。
由于我是调试，所以我必须多次运行许多场景。
我发现确保两台服务器进行完全握手的唯一方法是重新启动我的服务器。这将清除缓存和 session 信息，并强制服务器进行完全握手。
显然，每次我回来测试这个问题时都重新启动我的服务器并不理想。我做了一些研究，发现一些文章建议我可以通过将注册表项 HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\ClientCacheTime\Value 设置为 0 来禁用 SSL session 重用。
http://blogs.msdn.com/b/huizhu/archive/2009/12/17/ssl-_2f00_tls-full-handshake-vs.-abbreviated-handshake.aspx http://support.microsoft.com/kb/247658
文章建议这将禁用加密信息的缓存。但是，这对我不起作用。我错过了什么吗？
是否有另一种方法可以禁用 SSL session 重用或无需重新启动即可破坏缓存的方法？
最佳答案
这里有一些想法:
1) 让客户端清除他们的 session 缓存，如果这可能并且比重新启动他们的服务器更容易。
2) 通过 HTTPS 代理(例如 burpsuite)发送请求。这很可能需要配置客户端以使用您的代理。重新启动或清除代理缓存将导致完整的 TLS 握手。
3) 使用 TLS 反向代理接收服务器 IP 和端口上的传入请求，并将它们转发到服务器。客户端不需要代理配置。只需重新启动代理即可开始完整的握手。如果服务器需要 HTTPS，请在代理上使用上游 SSL。如果服务器可以使用 HTTP，您可以在代理和服务器之间明文发送流量，并使用 Wireshark 直接查看流量。这可能会有所帮助:https://serverfault.com/questions/583374/configure-nginx-as-reverse-proxy-with-upstream-ssl
4) 在客户端和服务器之间的现有 TLS 连接上翻转或丢弃数据包。这将导致致命警报(完整性检查失败，表明可能存在 MITM 攻击)，这将使该 session 无效并要求下一个请求启动完整的握手。
关于ssl - TLS 握手和 SSL session 重用，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/20433899/