.net 如何在特定的 HttpWebRequest 中使用 SSL3 而不是 TLS？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3028486/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How to use SSL3 instead of TLS in a particular HttpWebRequest?
提问by Anton Tykhyy
My application has to talk to different hosts over https, and the default setting of ServicePointManager.SecurityProtocol = TLSserved me well up to this day. Now I have some hosts which (as System.Nettrace log shows) don't answer the initial TLS handshake message but keep the underlying connection open until it times out, throwing a timeout exception. I tried setting HttpWebRequest's timeout to as much as 5mins, with the same result. Presumably these hosts are waiting for an SSL3 handshake since both IE and Firefox are able to connect to these hosts after a 30-40 seconds' delay. There seems to be some fallback mechanism in .NET which degrades TLS to SSL3, but it doesn't kick in for some reason.
我的应用程序必须通过 https 与不同的主机通信，ServicePointManager.SecurityProtocol = TLS直到今天，默认设置为我提供了很好的服务。现在我有一些主机（如System.Net跟踪日志所示）不响应初始 TLS 握手消息，但保持底层连接打开直到超时，引发超时异常。我尝试将HttpWebRequest的超时设置为 5 分钟，结果相同。据推测，这些主机正在等待 SSL3 握手，因为 IE 和 Firefox 都能够在 30-40 秒的延迟后连接到这些主机。.NET 中似乎有一些后备机制将 TLS 降级为 SSL3，但由于某种原因它没有启动。
FWIW, here's the handshake message my request is sending (a regular TLS 1.0 CLIENT HELLO message):
FWIW，这是我的请求发送的握手消息（常规 TLS 1.0 CLIENT HELLO 消息）：
00000000 : 16 03 01 00 57 01 00 00-53 03 01 4C 12 39 B4 F9 : ....W...S..L.9..
00000010 : A3 2C 3D EE E1 2A 7A 3E-D2 D6 0D 2E A9 A8 6C 03 : .,=..*z>......l.
00000020 : E7 8F A3 43 0A 73 9C CE-D7 EE CF 00 00 18 00 2F : ...C.s........./
00000030 : 00 35 00 05 00 0A C0 09-C0 0A C0 13 C0 14 00 32 : .5.............2
00000040 : 00 38 00 13 00 04 01 00-00 12 00 0A 00 08 00 06 : .8..............
00000050 : 00 17 00 18 00 19 00 0B-00 02 01 00 : ............
Is there a way to use SSL3 instead of TLS in a particular HttpWebRequest, or force a fallback? It seems that ServicePointManager's setting is global, and I'd really hate to have to degrade the security protocol setting to SSL3 for the whole application.
有没有办法在特定的情况下使用 SSL3 而不是 TLS HttpWebRequest，或者强制回退？似乎ServicePointManager的设置是全局的，我真的不想将整个应用程序的安全协议设置降级为 SSL3。
回答by Anton Tykhyy
Actually, ServicePointManagersettings are per-appdomain. This enabled me to work around the problem by creating a separate appdomain set up to use only SSL3, making my data collection object MarshalByRefObject(both WebClientand WebRequestare marshal-by-ref, but better to reduce the number of cross-appdomain calls) and creating it there. Worked perfectly combined with a timeout-based detection scheme.
实际上，ServicePointManager设置是针对每个应用程序域的。这使我能够解决此问题通过创建一个单独的应用程序域设置为只使用SSL3，使我的数据采集对象MarshalByRefObject（包括WebClient和WebRequest是元帅，副裁判，但是更能减少跨AppDomain的调用的数量），并创建它那里。与基于超时的检测方案完美结合。
回答by President James K. Polk
.NET contains provisions to automatically negotiate down to lower versions of the protocol. The value of ServicePointManager.SecurityProtocoldetermines the behavior. It can take on 3 different values: SecurityProtocol.Ssl3, SecurityProtocol.Tls, or SecurityProtocol.Ssl3 | SecurityProtocol.Tls. Although global, it can be changed as needed.
.NET 包含自动协商到较低版本协议的规定。的值ServicePointManager.SecurityProtocol决定行为。它可以采用 3 个不同的值：SecurityProtocol.Ssl3, SecurityProtocol.Tls, or SecurityProtocol.Ssl3 | SecurityProtocol.Tls. 虽然是全局的，但可以根据需要进行更改。
I cannot identify a solution without having access to a server with the same buggy behavior. About the only suggestion I can make is to attempt to connect with the Ssl3 | Tlssetting, and if that doesn't work then retry with the Ssl3setting. Try lowering the timeout and catching the timeout exception and then retrying.
如果无法访问具有相同错误行为的服务器，我将无法确定解决方案。我能提出的唯一建议是尝试连接Ssl3 | Tls设置，如果这不起作用，则重试Ssl3设置。尝试降低超时并捕获超时异常，然后重试。
EDIT
编辑
Much of what I wrote in the previous version of this answer was wrong.
我在这个答案的先前版本中写的大部分内容都是错误的。
