TLS v1.2 Configuration and Connection Errors

KB#1161: Last Updated February 12, 2019

To jump straight to the fix, click here: Registry Workaround

Recently, there have been an increasing number of issues for our support staff that involve our products connecting to servers that require TLS v1.2 for security reasons. Common examples include connecting to the following services:

GitHub – https://githubengineering.com/crypto-deprecation-notice/
Azure DevOps (formerly Visual Studio Team Services and Visual Studio Online)
Maven Central – https://blogs.apache.org/maven/entry/notice-java-6-and-7
npm registry
Inedo product update checking

The failure to connect to these services typically results in some variation of the following exception logged in the product’s Diagnostic Center or execution logs:

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

Technical Background

Hosted services have removed support for connections using earlier versions of the TLS protocol because they are vulnerable to attacks such as POODLE. Unfortunately for non-hostile consumers, this means that special consideration needs to be taken from the client side to ensure that the correct protocol version is used.

Why doesn’t Inedo software connect with TLS v1.2 by default?

The main reason is because our products are developed on the .NET platform, and the available protocols change depending on the targeted framework version when the application is built, not the actual framework or operating system installed on the server the product is running on. For more detailed information, see: Transport Layer Security (TLS) best practices with the .NET Framework

As of the latest major versions of each product, we target v4.5.2 of the .NET framework. In this version, TLS v1.2 is not one of the default values in the ServicePointManager, which all outbound TCP or HTTP connections use by default. If we were to target v4.7 for example, these issues would never emerge. However, changing the targeted framework is a non-starter because many of our enterprise customers cannot simply install the latest framework version without a great deal of change management bureaucracy. Historically, we have changed it twice, and only during major version upgrades (v2.0 🡒 v3.5 🡒 v4.5.2).

Possible Code Fix

Another “fix” that allows upgraded connections (though it would require new versions of the products or extensions anyway) could be achieved using the following code:

System.Net.ServicePointManager.SecurityProtocol 
    |= SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

When most of BuildMaster’s early code was developed, TLS v1.2 was not even finalized as a standard; and even after it became finalized, the earlier versions were de facto secure because these attacks had not been discovered yet. Of course, this fix is only temporary because the same problem will occur in the future when TLS v1.2 is deprecated and superseded by TLS v1.3 or an entirely new protocol altogether. Oh, and even Microsoft recommends against this:

“To ensure .NET Framework applications remain secure, the TLS version should not be hardcoded”

Registry Workaround

To resolve these errors, the following registry key can be added to the Inedo product server in order to force pre-v4.7-targeting .NET framework applications to use the most secure protocol established by the operating system:

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
Value: SchUseStrongCrypto
Data: 1

Once this key is added (or its data set to 1), it will require the server to be rebooted.

Support