0

When I try to connect to a website I get the error:

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

The Status in the exception is SecureChannelFailure, the Response is null.

Searching StackOverflow for answers has not helped me so far. I tried all the solutions:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
ServicePointManager.Expect100Continue = true;
ServicePointManager.ServerCertificateValidationCallback += (sender, cert, chain, sslPolicyErrors) => true;

The ServerCertificateValidationCallback never gets called.

I can open the website in Firefox and Edge(Chromium) without problems, but the Internet Explorer can't make a secure connection to it. So I assume that HttpWebRequest is using the same "mechanics" as Internet Explorer, but I can't figure out which.

On https://server.cryptomix.com/secure/ I ensured, that I don't have a client SSL certificate presented. That means that I don't have to add ClientCertificate to the request.

Here is my whole test code:

public static void Main()
{
    ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
    ServicePointManager.Expect100Continue = true;
    ServicePointManager.ServerCertificateValidationCallback += (sender, cert, chain, sslPolicyErrors) => true;

    HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create(new Uri(@"https://netmap.vodafone.de"));

    request.Method      = "GET";
    request.ContentType = "text/json";

    try
    {
        using (var response = (HttpWebResponse)request.GetResponse())
        {

        }
    }
    catch (Exception e)
    {
        throw;
    }
}

Do you have any idea, why I can connect with Internet Explorer and HttpWebRequest, but with Firefox it's possible?

Do you get the same error when you run the code?

Edit: I found out, that the website is using TLS 1.3, but there is no SecurityProtocolType.Tls13 enum value.

user11909
  • 1,235
  • 11
  • 27
  • Have you tried using SecurityProtocolType.Tls11 – Jawad May 06 '20 at 05:48
  • @Jawad Yes, same error. – user11909 May 06 '20 at 05:49
  • You can use other proxy settings that system's with firefox. Do you have a special proxy configured in FF, but not in IE(=system)? Also, I cannot call https://netmap.vodafone.de by myself(404) in my browser. – Chrᴉz remembers Monica May 06 '20 at 06:14
  • @ChrᴉzsaysreinstateMonica It's not the whole URL, but for testing it is enough. You can still connect to the host, but don't get a website. I found out that it's using TLS 1.3, which IE and .NET does not support ATM. – user11909 May 06 '20 at 06:23
  • What .NET version are you using? The .NET Framework 4.6 includes a new security feature that blocks insecure cipher and hashing algorithms for connections. – kapsiR May 06 '20 at 06:25
  • @kapsiR .NET Framework 4.7.2 – user11909 May 06 '20 at 06:26
  • 2
    It seems this has to be an issue on your client. (I bet on issues with the cipher suites, the site has a pretty good TLS configuration) What OS do you have and is it [fully patched](https://stackoverflow.com/a/46472420)? – kapsiR May 06 '20 at 06:33
  • 1
    The best way of debugging is to use a sniffer like wireshark or fiddler. Compare the headers in first request with Firefox with headers in first request with c#. Then make the c# headers look exactly like the Firefox headers.The default headers in c# are different from Firefox.Mostly likely it is the content type header which is the type of browser. The HttpWebRequest you can put any content type.Your default browser on the machine is probably IE so c# is adding the IE content type to the request and the server is rejecting IE. So simply use the content type that is in the working Firefox. – jdweng May 06 '20 at 07:23
  • @kapsiR You were right: The cipher suite differ. I will investigate further, thank you. – user11909 May 06 '20 at 09:17
  • @user2190035 Thanks for updating. I added this as answer to the question that you can mark it as accepted – kapsiR May 06 '20 at 10:13
  • @jdweng - if you're getting an error of "Could not create SSL/TLS secure channel" then you don't get the secure channel, let alone a chance to start sending headers. – Damien_The_Unbeliever May 06 '20 at 10:16
  • Don't put the Cart before the Horse. You have to start the request before you create the secure channel. HTTP use for the transport layer TCP. A HTTP consists of one or more TCP message (TCP max is ~1500 bytes). So what actually happens is the HTTP Request is broken down into multiple TCP messages where the TCP does the SSL/TLS. But the TCP is driven by the HTTP Request. Not the TCP coming out of thin air. The TCP (TLS/SSL) parameters are part of the HTTP Request. – jdweng May 06 '20 at 10:49
  • @jdweng - [Server Name Indication](https://en.wikipedia.org/wiki/Server_Name_Indication): "However, when using HTTPS, the TLS handshake happens before the server sees any HTTP headers." – Damien_The_Unbeliever May 06 '20 at 14:37
  • Are you sure? You have to look at both the TCP and HTTP on sniffer to see the actual timing. A client may send non secure HTTP to Server and then Server will attempt automatically to switch to secure mode. – jdweng May 06 '20 at 14:55
  • @jdweng - you're confusing an attempt to connect via HTTP which (absent many client/server details) may result in a redirect to HTTPS and an HTTPS request (such as that in the question) that requires a secure channel (via TLS) to be obtained first. – Damien_The_Unbeliever May 06 '20 at 19:23
  • The TCP SSL/TLS doesn't just get sent without something driving the message. So there is always a HTTP request before a TCP. – jdweng May 06 '20 at 19:57

2 Answers2

0

I had the same issuze in one of my projects before. This worked out for me:

ServicePointManager.Expect100Continue = true;
    ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls
           | SecurityProtocolType.Tls11
           | SecurityProtocolType.Tls12
           | SecurityProtocolType.Ssl3;

It requires the System.Net Namespace.

Marvin Klein
  • 1,436
  • 10
  • 33
  • Be careful of or'ing TLS11, 12, 13. The client does not automatically try all 3 modes. Or'ing just means the client will accept a response of any one of the three. The client must provide a loop and if the first gets rejected then tries the 2nd and then the 3rd. – jdweng May 06 '20 at 10:56
0

It seems this has to be an issue with your client.

I bet on issues with the cipher suites, the site has a pretty good TLS configuration (data from ssllabs.com): enter image description here

Please check your OS (fully patched?) for support.

kapsiR
  • 2,720
  • 28
  • 36
  • 1
    The client configuration was missing Cipher Suites. I was able to enable the required Cipher Suite with the program "IIS Crypto". – user11909 May 07 '20 at 07:02