HttpWebRequest to SSL fails

Question

I'm using this code, to make a request to a given URL:

private static string GetWebRequestContent(string url)
{
  string sid = String.Empty;

  HttpWebRequest req = (HttpWebRequest)HttpWebRequest.Create(url);
  req.KeepAlive = false;

  using (HttpWebResponse res = (HttpWebResponse)req.GetResponse())
  {
    using (StreamReader sr = new StreamReader(res.GetResponseStream()))
    {
      sid = sr.ReadToEnd().Trim();
    }
  }

  return sid;
}

I'm using it to test the stickyness of a Work Load Balancer, with 3 servers behind it. They all have a static HTM file called sid.htm, where the server's Server ID is written.

For URL's with HTTP this works fine. But with HTTPS it doesn't work. I get this exception:

The request was aborted: Could not create SSL/TLS secure channel.

At the moment, I have only 2 servers behind the WLB and one on its own with a public IP behind a firewall. HTTPS requests works fine if I hit the stand-alone server - but when I hit the WLB I get the above error.

One thing: In order to switch between hitting the single server, and the WLB I use my hosts file. The DNS records for my domain points to the single server at the moment. So I put a record in my hosts file to hit the WLB. This shouldn't be causing problems...

My question: Which SSL credentials/certificates does the HttpWebRequest use? If it uses 40 bit DES or 56 bit DES, that's the reason, because those are disabled in the WLB. But those certificates haven't been used in browsers since IE3 and Netscape 1 and 2.

Answer 1

It works perfectly in my browser.

I found the solution 1 minute after i posted the question:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

And that means the HttpWebRequest was using TLS 1.0 - I don't know, but I assume that is 40 bit DES or 56 bit DES, which is disabled in the WLB.

Answer 2

There is smothing you might want to consider with the load balancer. The ones we use forward the HTTPS secure traffic to the servers behind it on an insecure HTTP connection. The connection between the load balancer and the browser is still secure but there is no need for the over head of the secure protocol between the balancer and the web servers.

We wanted to detect a secure connection on our web servers but initially never saw an HTTPS connection. That's when we realised the traffic behind the balancer was all insecure. Made sense once we knew.

What we do now is forward all secure traffic coming into the balancer (port 443) to port 81 (altenative HTTP) and then forwarded all normal HTTP traffic (ports 80 & 81) to port 80. Then we can check the port on the web server and know 80 is insecure and 81 is secure traffic between browser and balancer despite the fact its all HTTP at the web server.

Answer 3

@Dave: We have SSL Proxy on WLB, and top notch Cisco consultants to take care of this. I know we are extremely secure, regarding this.