3
votes

I have set up a simple .NET 4.6 web server, using the HTTPListener with a 'https' prefix and linked certificate on a server 2012 R2 machine. The https interface works, but only uses TLS 1.0 and not 1.1 or 1.2, which should be supported by default by the server 2012.

What I have tried so far, to force the system to use TLS 1.2:

  • added and enabled SCHANNEL protocol in the registry for TLS 1.2
  • added and enabled SchUseStrongCrypto in the registry for the .NET framework
  • disabled SCHANNEL protocol for TLS 1.0 and SSL in the registry
  • hardcoded via System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;

But none of these seem to have the desired effect. When SSL and TLS 1.0 are disabled through SCHANNEL registry, the webserver becomes unreachable.

Framework .NET 4.6.2 has been installed. The executable has been built against .NET 4.6. Any hints?

Cheers.

1
I am not sure how to force this in a selfhosted application, but for IIS I previously used a tool IIS crypto (nartac.com/Products/IISCrypto) ... although it's meant for IIS, it alters the registry values. It might help you. Use at your own risk of course.Stefan
No luck. I assume that behind the scenes, that software just sets the relevant registry settings in a.o. the SCHANNEL section, which I did manually.BasiK
Becomes unreachable how? Trace the flow using Wireshark and confirm that the TLS handshake is failing -- and why it's failing. It need not be TLS 1.2 per se, it could also be a failure to reach agreement on algorithms. You don't specify what client software and configuration you're using to test the server.Jeroen Mostert
Used a web browser to verify connection: - chrome: err_conn_reset, due to TLS lower than 1.1; if I force chrome on tls1, I can get a connection - IE: connection works. Checking the properties of the connection shows tls 1.0. If tls 1.0 gets disabled, the security falls back to SSL 3.0.BasiK
That still tells you nothing about how and why, beyond "TLS 1.2 is not used for some reason". If you're not comfortable reading network traces, consider using OpenSSL's openssl s_client to get details.Jeroen Mostert

1 Answers

0
votes

Typing it in an answer as it might still be helpful, and its not just a comment.

In my case I was able to see main SSL handshake via Fiddler and see which cipher suite is being selected - although my case was the SSL client requesting strong specific ciphers with TLS1.2 to the server to work but I think it would not be much different the other way round. Secondly I have enabled all what you have mentioned in your question plus I also had to enable these in my app config file to finally make it to work.

<compilation targetFramework="4.6" />
<httpRuntime targetFramework="4.6" />