0700 TLS 1.2 Upgrade Workflow

Introduction

TLS 1.2 is a more secure protocol than TLS 1.0, which SQL Server has used historically. This workflow describes the ideal order of upgrade steps and discusses some things to keep in mind while performing the upgrade.

The following KB article goes over which SQL servers and drivers and other components can and need to be upgraded:

	https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/connect/tls-1-2-support-microsoft-sql-server
	https://support.microsoft.com/en-us/kb/3135244

	Public SharePoint-specific TLS 1.2 upgrade article - covers more than just SQL upgrades
	https://technet.microsoft.com/en-us/library/mt773991.aspx

Steps

In order to implement TLS 1.2, the following steps must be taken:

1. Identify SQL Servers and install the latest patches on them. Make sure TLS 1.2 is not disabled; it is enabled by default. If unsure, run SQLCHECK.
2. Identify client machines and applications that connect to SQL Server and apply patches on them.
3. Turn off TLS 1.0 on client machines.
4. Turn off TLS 1.0 on the servers. This may turn up missed client machines.

TLS 1.2 Challenges

There are a number of challenges to the above.

1. Identifying SQL Servers to be patched is relatively easy. The real challenge is in identifying the clients that require updates and which updates they need. A single machine may have applications that use several different drivers – OLE DB, ODBC, and .NET. This might require a very careful and thorough inventory.

2. Some drivers CANNOT be patched to TLS 1.2. The most common are the SQL Server 2000 legacy drivers that ship with Windows, I.e. Provider=SQLOLEDB or Driver={SQL Server}. In these cases it will be necessary to rewrite or reconfigure the connecting application to use a SQL 2008 or later driver or Provider.

Note: SQL 2005 SNAC drivers (Provider=SQLNCLI and Driver={SQL Server Native Client}) are not supported anymore, unlike the drivers that ship with Windows.

If the application cannot be rewritten, e.g. source code lost or it is a 3rd-party application and the vendor went out of business or will not rewrite it, then you cannot turn off TLS 1.0 for that client or the target server.

3. Turning off TLS 1.0 on the SQL Server might likely reveal some non-compliant clients in the environment. DBAs will have to work with the various application development teams to determine which drivers the applications use and upgrade and test.

4. Turning off TLS 1.0 on a client machine that otherwise fails to connect to a SQL machine running TLS 1.2 and has TLS 1.0 disabled may allow the application to connect. However, this is not typically acceptable for the requirements of most enterprises and so should be avoided. Instead of trying to negotiate an SSL hash for the conversation, the client will connect using an unencrypted Login7 packet, revealing user credentials to any listener on the connection. You can observe this readily in a network trace if the client is on a different machine.

Resources

The following tools and articles can make some of the validations and setting changes easier.

USE WITH CARE – CHANGING TLS SETTINGS CAN MAKE THE SYSTEM OR SERVICE UNUSUABLE

Note: Export the registry branch using Regedit.exe so you can have a backup of the original settings.

https://www.nartac.com/Products/IISCrypto/ This tool allows you to easily see what TLS and SSL client and server protocols are enabled and to change them. It also allows you to enable or disable various cipher suites. This can break existing applications in the environment if done incorrectly, so should not typically be done without the guidance of Microsoft support. NOTE: IISCrypto is a non-Microsoft tool.

https://support.microsoft.com/en-us/kb/245030 This article goes over the SSL and TLS client and server registry keys and how to enable and disable via REGEDIT.