43

I need to upgrade a .NET application to support a call to an API on a website that only supports TLS 1.2. From what I read, if the application is targeting 4.6 or higher then it will use TLS 1.2 by default.

To test I created a Windows Forms app that targets 4.7. Unfortunately it errors when I don't explicitly set ServicePointManager.SecurityProtocol. Here is the code:

HttpClient _client = new HttpClient();

var msg = new StringBuilder();

// If I uncomment the next line it works, but fails even with 4.7
// ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

var httpWebRequest = (HttpWebRequest)WebRequest.Create("https://sandbox.authorize.net");

httpWebRequest.KeepAlive = false;

try
{
    var httpWebResponse = (HttpWebResponse) httpWebRequest.GetResponse();

    msg.AppendLine("The HTTP request Headers for the first request are: ");

    foreach (var header in httpWebRequest.Headers)
    {
        msg.AppendLine(header.ToString());
    }

    ResponseTextBox.Text = msg.ToString();

}
catch (Exception exception)
{
   ResponseTextBox.Text = exception.Message;

   if (exception.InnerException != null)
   {
       ResponseTextBox.Text += Environment.NewLine + @"  ->" + exception.InnerException.Message;

       if (exception.InnerException.InnerException != null)
       {
            ResponseTextBox.Text += Environment.NewLine + @"     ->" + exception.InnerException.InnerException.Message;
       }
   }
}

If you uncomment out the following line:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

it works. This isn't a good solution since it hard codes what TLS version to use, so it wouldn't use TLS 1.3 in future.

What else do I need to do to get it work without having this line. I'm testing from a Window 10 machine with 4.7 installed.

Update

I tried a test with HttpClient and had the same results, I had to explicitly set SecurityProtocol.

Code:

var msg = new StringBuilder();

// Need to uncomment code below for TLS 1.2 to be used
// ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

try
{
   var response = await _client.GetAsync(@"https://sandbox.authorize.net");

   msg.AppendLine("response.IsSuccessStatusCode : " + response.IsSuccessStatusCode);

   msg.AppendLine(await response.Content.ReadAsStringAsync());

   textBox.Text = msg.ToString();
  }

  catch (Exception exception)
  {
      textBox.Text = exception.Message;

      if (exception.InnerException != null)
      {
          textBox.Text += Environment.NewLine + @"  ->" + exception.InnerException.Message;
      }
   }
Josh
  • 7,099
  • 11
  • 65
  • 109
  • 1
    You can OR the tls versions together to support them all if you want. But to avoid the need for this use HttpClient (if you can make your code async without any blocking calls) – Crowcoder Jun 25 '17 at 23:51
  • 2
    I don't want to define the security protocol because when a new one, such as TLS 1.3 becomes available, it wouldn't be used because it isn't in the list. I'll rewrite my test with HttpClient, is there a difference the default Security Protocol used by HttpClient vs HttpWebResponse? – Josh Jun 26 '17 at 15:07
  • Don't take my word for it, but I assume HttpClient will support negotiation of the highest protocol available for the version of CLR. So, your next brick wall will require a CLR upgrade instead of code upgrade. This is probably a horrible idea, but I wonder what would happen if you just turn on all bits: `SecurityProtocolType s = (SecurityProtocolType)2147483647;` – Crowcoder Jun 26 '17 at 15:38
  • @Crowcoder, same result with HttpClient, updated question code used. – Josh Jun 26 '17 at 15:39
  • 1
    Interesting. Check out this release note about v4.7 https://github.com/Microsoft/dotnet/blob/master/releases/net47/dotnet47-changes.md#networking – Crowcoder Jun 26 '17 at 15:47
  • 1
    It is interesting. I tried to set it to "SystemDefault" but that failed. Assuming it is the default value, then TLS 1.2 should be the value used on Win10 OS. – Josh Jun 26 '17 at 17:43
  • If this was a web application, would setting `SecurityProtocolType` affect both the "outgoing" traffic from the web app (such as someone calling a http GET method to your site) and external calls made from within the app to some external service? (using HttpClient for example) – Jim Aho Apr 26 '18 at 08:59
  • "If I uncomment the next line it works, but fails even with 4.7" It works but it fails? What do you mean? Does it work if you set it to SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls or does it work only when you set it to SecurityProtocolType.Tls12? – osexpert Nov 07 '18 at 10:34
  • The .NET 4.7 documentation is incorrect. It will not use the best available protocol but the “OS default” one. On Windows 7 this is TLS 1.0 and .NET 4.7 will not negotiate a better protocol version. That’s why connecting to servers which run newer TLS will fail. – Jozef Izso Aug 12 '19 at 09:50
  • It is only 4.7.1 or above that uses OS TLS version to negotiate. WCF Supports TLS1.0, 1.1 and 1.2 as the default in .NET Framework 4.7. Starting with .NET Framework 4.7.1, WCF defaults to the operating system configured version. If an application is explicitly configured with `SslProtocols.None`, WCF uses the operating system default setting when using the NetTcp transport. – Hakeem Ojulari Mar 03 '20 at 18:55

6 Answers6

21

Starting with apps that target the .NET Framework 4.7, the default value of the ServicePointManager.SecurityProtocol property is SecurityProtocolType.SystemDefault.

This change allows .NET Framework networking APIs based on SslStream (such as FTP, HTTPS, and SMTP) to inherit the default security protocols from the operating system instead of using hard-coded values defined by the .NET Framework.

That's the reason of the new behaviour you experienced and the need of the new configuration:

<runtime>
   <AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols=false;Switch.System.Net.DontEnableSchUseStrongCrypto=false" /> 
</runtime>

See here and here

Update (useful info)

Keep in mind, best security practices suggest to update your IIS configuration disabling, time by time, old protocols and ciphers key (e.g. TLS 1.0, 1.1). See Setup Microsoft Windows or IIS for SSL Perfect Forward Secrecy and TLS 1.2 for very interesting info.

If you follow this practice, you don't need to set the configuration above (as MS suggests), because your Win server / IIS is already well configured.

Of course, this is possible only if you have access to the server with proper grants.

Gianpiero
  • 2,878
  • 1
  • 25
  • 33
16

I had the same issue (Windows 10 and SSL3 / TLS only... not System Default) with a legacy app targeting 4.7.2. My issue was that during the upgrade process over the years we never added in the targetFramework to the system.web > httpRuntime element (Note: it did exist on system.web > compilation element). Before taking bigger steps, ensure your system.web looks something like the following:

<system.web>
    <compilation targetFramework="4.7.2"></compilation>
    <httpRuntime targetFramework="4.7.2" />
</system.web>

In the above example, swap 4.7.2 for whatever version of the framework you are currently using that is >= 4.7.

scottheckel
  • 8,643
  • 30
  • 42
10

As an alternative to Nick Y's answer, I discovered that on Windows 7 using .NET 4.7+, I needed to enable these registry settings in order for the Microsoft Secure Channel (Schannel) package to properly send TLS1.1 and TLS1.2.

This allows the .NET client to continue to have System.Net.ServicePointManager.SecurityProtocol set to SystemDefault and get TLS 1.1 and 1.2 on a Windows 7 computer.

Using the SystemDefault option allows .NET to defer the selection of protocols to the OS. This means that when Microsoft releases hotfixes to the OS to disable insecure protocols or enables support for new ones in their native SCHANNEL library, .NET framework apps running will automatically get this new behavior.

Here are the registry entries:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000
MerickOWA
  • 7,145
  • 1
  • 32
  • 54
  • 1
    Worked for 2008 R2 as well. – Brian Aug 22 '18 at 19:03
  • "This allows the .NET client to continue to have System.Net.ServicePointManager.SecurityProtocol set to SystemDefault" Won't "Switch.System.Net.DontEnableSystemDefaultTlsVersions=true" also allow SecurityProtocol to be SystemDefault? In case it is better to edit config file than messing with registry IMO. – osexpert Nov 07 '18 at 11:00
  • 2
    @osexpert no. If you set "DontEnableSystemDefaultTlsVersion=true" you disable the OS's default protocols and only enable the default protocols in the installed version of .NET. In my case, If the OS is patched to enable new protocols, I want them enabled. I didn't want to update the application's config or .NET framework version just to enable new versions of TLS. – MerickOWA Nov 08 '18 at 16:55
  • 1
    @osexpert See my updated answer as to why this might be advantageous vs changing the app to disable the SystemDefault. – MerickOWA Nov 08 '18 at 17:04
  • ".NET framework apps running will automatically get this new behavior" yes it sounds good, but it does not seem to work in real life when they must be enabled in registry as well? Imagine tls1.3 came, this too would not work without a new registry change? Not very automatic. – osexpert Nov 08 '18 at 20:59
  • 1
    @osexpert I'm pointing out that this might be a OS configuration issue, not a .NET application problem. – MerickOWA Nov 08 '18 at 21:06
  • 2
    Agreed with Merick, using SystemDefault is recommended by Microsoft and enabling newer version TLS should be the job of windows update/hotfix; – Yang Nov 08 '18 at 22:35
  • Another found to mention: if the targetFramework attribute value > 4.7 in , the following AppContextSwitch command could not disable system default security protocol for web applications (however it works for console application) ` ` – Yang Nov 08 '18 at 22:38
  • @osexpert Managing the system default (which happens to be in the registry) for an enterprise via group policies is going to scale much better than trying to find and maintain individual application settings. – brianary Dec 19 '18 at 17:17
8

I've found one solution. It doesn't answer the question about why TLS 1.2 isn't being used by default on Win10 with .NET 4.7, but it does allow me not to have to set ServicePointManager.SecurityProtocol.

The solution that worked from both my 4.5.2 and 4.7 test apps is to add the following to app.config:

<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=false"/>

Here the whole app.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <startup> 
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7"/>
    </startup>
    <runtime>
      <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=false"/>
    </runtime>
</configuration>
Josh
  • 7,099
  • 11
  • 65
  • 109
  • 1
    This make no sense. The default value of Switch.System.Net.DontEnableSchUseStrongCrypto is already false. false: don't use insecure protocols (SSL), true: allow insecure protocols. This should not be related to TLS1.2 at all. I don't deny it is working (I have not tested), just saying it make no sense. – osexpert Nov 07 '18 at 10:42
  • 2
    I tried this in a simple console application that makes a `HttpClient` request to a TLS 1.2-only web-service and I ran the console program on Windows 7 SP1. Unfortunately it had zero effect. Downvoting. – Dai Nov 25 '18 at 06:54
  • 1
    I've tried all of the answers on this thread on a windows 10 machine running a unit test project in 4.7.2 and the only thing that works is hard coding `ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls12;` -- *shakes fist at Microsoft* – Will P. Jun 14 '19 at 15:48
  • Yes, this solution has no effect on Windows 7 SP1. – Jozef Izso Aug 12 '19 at 09:51
7

I am on Windows 7 and .NET 4.7.1

The recommendation to use Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols and Switch.System.Net.DontEnableSchUseStrongCrypto mentioned in two other answers did not work in my project and OP's code was failing too.

Reviewing source code for ServicePointManager and LocalAppContextSwitches I came across another config setting which worked.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=true" />
</runtime>
Nick Y
  • 172
  • 1
  • 5
  • See my answer for an alternative which still allows .NET to keep its "SystemDefaultTls" setting – MerickOWA Jul 13 '18 at 18:54
  • This config setting works for console application only. Web application targeting to 4.7 or above will always have System.Net.ServicePointManager.SecurityProtocol = SystemDefault unless it is hard-coded explicitly to other protocols (which is not recommended) – Yang Nov 08 '18 at 22:29
0

Windows 7 has TLS1.2 and TLS1.1 disabled by default. Enabling it in IE has no effect for other applications.

You should enable it by registry: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "DisabledByDefault"=dword:00000000

Very useful article with script to set as only TLS1.2