How to use SSL3 instead of TLS in a particular HttpWebRequest?

Question

My application has to talk to different hosts over https, and the default setting of ServicePointManager.SecurityProtocol = TLS served me well up to this day. Now I have some hosts which (as System.Net trace 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.

FWIW, here's the handshake message my request is sending (a regular TLS 1.0 CLIENT HELLO message):

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.

Answer 1

Actually, ServicePointManager settings 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 WebClient and WebRequest are 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.

Answer 2

.NET contains provisions to automatically negotiate down to lower versions of the protocol. The value of ServicePointManager.SecurityProtocol determines the behavior. It can take on 3 different values: SecurityProtocol.Ssl3, SecurityProtocol.Tls, or SecurityProtocol.Ssl3 | SecurityProtocol.Tls SecurityProtocol.Ssl3, SecurityProtocol.Tls, or SecurityProtocol.Ssl3 | SecurityProtocol.Tls . Although global, it can be changed as needed.

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 | Tls Ssl3 | Tls setting, and if that doesn't work then retry with the Ssl3 setting. Try lowering the timeout and catching the timeout exception and then retrying.

EDIT

Much of what I wrote in the previous version of this answer was wrong.