C# HttpWebRequest SEC_I_RENEGOTIATE Intermittent Errors

Question

I\'m working on login / logout functionality using SSL POST calls in a C# (.Net framework 3.5) application. Getting the response from the server via HttpWebRequest::BeginGe

Answer 1

I thought I'd share my experience as I've been reading most of the stackoverflow questions on this lately:

Another approach to this which I've seen work is to consider HTTP Keep-Alive. With latest versions of .Net it uses HTTP 1.1 as default which means Keep-Alive is set to true and Expect100 on as well.

From my experience this creates stickiness on resources downstream and isn't reliable behind a load balancer.

Two choices

1) Recover and try again which seems slightly smelly. However as Khanfx mentions, network problems can happen ergo: fallacies of networks. TOPAZ is one way of solving this problem: https://msdn.microsoft.com/en-us/library/hh680901%28v=pandp.50%29.aspx?f=255&MSPPError=-2147217396

2) Turn off Keep-Alive either via HttpwebRequest or emitting a connection close header if using HttpClient.

HTH.

Answer 2

(For the original answer, see below.)

What this error usually means is that your client and server are not set to use the same type of encryption. Often, the simplest method of fixing this is explicitly setting the version to use in the client.

If you are using .NET 4.5 or newer, here are the options to try, in order from most secure to least secure:

• ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
• ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11;
• ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls;

If you are using .NET 4.0 or older, you can only use the last line above, as those versions do not support TLSv1.1 and TLSv1.2. It is highly recommended that you upgrade to .NET 4.5 to take advantage of TLSv1.2 support.

In addition to setting the SecurityProtocol property, you may also have to set: ServicePointManager.Expect100Continue = true;

If none of these settings helps, it likely means that your server only supports SSLv3 (or, even worse, SSLv2). If that is the case, upgrade your server! SSLv3 is broken and should no longer be used.

---

SSLv3 is NO LONGER considered secure. DO NOT use these settings! While this was the correct answer in 2011, it remains here only for historical reasons.

You need to add the following lines of code before your request:

ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

From what I have seen, older versions (.NET 2 and/or Windows xp/2003 and older) used these as the default options but newer versions (.NET 3 and/or Windows Vista/2008 and newer) do not.

Answer 3

This is not an explanation, nor a true solution: it's simply the most pragmatic way of dealing with this issue that we've found in our case (doing a WCF SOAP request over HTTPS using a client SSL cert with an Apache & Java based server).

Catch SecurityNegotiationException and retry on-the-spot (i.e. rather than reprocessing the message, if using msmq), and suppress reporting the exception in this case. Just inc a performance counter or something simple like that so you can track whether the problem gets any worse.

At the end of the day, this is just one of those innate network-related problems that your code needs to deal with.