31
  • The major browsers are moving beyond SSL3.0 and TLS1.0 .
  • The PCI Security Council has declared an end-of-life date for these protocols to be considered sufficiently strong encryption.

We need to move away from these protocols, to use newer and stronger ones. On Windows servers, you can very easily disable these old protocols, and instead offer only TLS1.1 or greater. However, as noted elsewhere, Microsoft SQL Server 2008 R2 and SQL Server 2012 (Standard, at least) both will not start if those lower protocols are disabled. However, there are a growing number of versions of MS SQL Server. There are SQL Server Standard, Business Intelligence, Enterprise, Express, Web, and Compact editions. And of course there is SQL Server 2008, 2012, 2014, and (in pre-release) 2016.

Which of these editions support or will support the use of only TLS1.1 or greater protocols?

1
  • As a side note: the PCI requirements here cover overall data transmission, so wrapping any SQL comms over public and/or wireless networks in a VPN/tunnel that implements better standards should be sufficient. They may also not cover local communications at all either; so if nothing outside your VLAN can even touch the SQL instance due to appropriate SQL configuration and/or firewalls & other filtering, you may not need to be concerned from this PoV. Neither of these facts help you if you need to expose a SQL instance to the public network of course, but that idea scares me anyway! Mar 3, 2016 at 10:26

6 Answers 6

19

Microsoft has recently revealed (without a lot of fanfare) that they will be investing in TLS 1.2 and phasing out SSL. It should be relevant to all editions of SQL Server.

UPDATE 2016-01-29 : Microsoft has announced official support for TLS 1.2 in 2008, 2008 R2, 2012, & 2014. Downloads and other info can be found in KB #3135244.

I blogged about a few of the issues that have been mentioned, as well as a warning if you are using encrypted endpoints in 2014:

The post also points to the correct build to download (or other action) depending on @@version.

Whether this move will affect all existing versions, just 2014 and above, or just 2016, remains to be seen. The quote below seems to imply at least 2014 will be part of the work - and I suspect much of the investment will be in the client libraries, not in the engine, so it is feasible that it will work for any version that the next release of the ODBC/Native Client drivers will support.

I got this from a PowerPoint deck by Kevin Farlee of Microsoft, and was given permission to share the information, though I don't know how much of it has been redistributed at this point. Here is the exact quote from the deck:

Encryption in flight: Protects data between client and server against snooping & man-in-the-middle attacks. Upgrading to TLS 1.2 in CY 15, phasing out SSL.

Also if you look at KB #3052404, it seems there are patches to make it work with 2012 SP+ and 2014 (patches won't be required for 2016), but no indication there will be any back-porting to SQL Server 2005, 2008, or 2008 R2 (and frankly, I'd be quite surprised).

0
6

As in the other answers: you need a recent CU for TLS1.2. See:

FIX: You cannot use the Transport Layer Security protocol version 1.2 to connect to a server that is running SQL Server 2014 or SQL Server 2012:

  • Cumulative Update 1 for SQL Server 2014 SP1
  • Cumulative Update 8 for SQL Server 2014
  • Cumulative Update 1 for SQL Server 2012 SP3
  • Cumulative Update 10 for SQL Server 2012 SP2

After enabling only TLS 1.2 you will possibly encounter two errors:

  1. SQL Server 2014 Agent will not start. Solution: install SQL Server 2012 SNAC from the download link in KB3135244
  2. SQL Server Management Studio can't connect. Solution: Install the applicable .NET framework hotfix from KB3135244

Furthermore you have to update the SNAC/OBDC driver on all clients connecting to the SQL Server.

The complete list of SQL Server and Client Driver builds, along with download links, and other configuration changes that may be needed are contained in the following Microsoft Support Knowledge Base article:

TLS 1.2 support for Microsoft SQL Server

0
4

As of January 29th 2016, Microsoft SQL Server supports TLS 1.2 for:

  • SQL Server 2008
  • SQL Server 2008 R2
  • SQL Server 2012; and
  • SQL Server 2014

...and major client drivers like:

  • Server Native Client
  • Microsoft ODBC Driver for SQL Server
  • Microsoft JDBC Driver for SQL Server
  • ADO.NET (SqlClient).

Blog post by the SQL Server Engineering Team about the release:

TLS 1.2 Support for SQL Server 2008, 2008 R2, 2012 and 2014

List of builds that support TLS 1.2 along with the client and server component download locations (KB3135244):

TLS 1.2 support for Microsoft SQL Server (includes .NET fixes for DB Mail)

Note: The above has been updated since the initial release to address a defect in the original update that caused intermittent service termination when connecting to an instance of SQL Server 2008 or SQL Server 2008 R2. This is described in KB 3146034:

Intermittent service terminations occur after you install any SQL Server 2008 or SQL Server 2008 R2 versions from KB3135244

2

I can confirm that as SQL 2012 SP2 CU7, which has the TLS 1.2 support for SQL 2012 from CU6, you cannot disable TLS 1.0 at the server level and be able to connect to SQL server using an un-encrypted management studio connection on an instance which does not force client encryption.

This is on an instance that does not use TDE or other certificates.

I will try tomorrow after generating a trusted certificate for the server and enabling encrypted connections, but at this time TLS 1.0 cannot be disabled on SQL 2012, even though it supports TLS 1.2.

Edit:

I generated a certificate for the database server from our internal Certificate Authority and was able to establish an encrypted management studio connection to SQL server, until the TLS 1.0 protocol was disabled at which point I was no longer able to connect. The same behavior as when not having a cert and a self-signed cert is used to encrypt the login session.

2

I found, even with SQL 2014 SP1 CU1, I had to use separate boxes for IIS and SQL. I ran into a few apparently-related problems along the way, and detailed the steps in this post.

The key points are:

  • Put IIS and SQL on separate boxes
  • Disable incoming TLS1.0 and enable outgoing TLS1.0 on the IIS box
  • Enable TLS1.0 both ways on the SQL box.
0
1

Here is what I did on both front and back servers

  1. Open gpedit.msc. In the Local Group Policy Editor, double-click "Windows Settings" under the "Computer Configuration" node, and then double-click "Security Settings".

  2. Under the "Security Settings" node, double-click "Local Policies", and then click "Security Options".

  3. In the details pane, double-click "System cryptography: Use FIPS-compliant algorithms for encryption, hashing, and signing".

  4. In the "System cryptography: Use FIPS-compliant algorithms for encryption, hashing, and signing" dialog box, click "Enabled", and then click "OK" to close the dialog box. Close the Local Group Policy Editor.

2
  • I assume this is to address how to set up TLS 1.2, as opposed to the actual original question, of which versions of SQL Server do support something beyond TLS 1.0, perhaps on a webserver with a SQL backend? If possible, please clarify this in the answer itself.
    – RDFozz
    Nov 20, 2017 at 15:36
  • Thanks, but ... In the original question, I tried to make it somewhat general, but it really had to do with matching up a minimum requirement and a set of technologies back in mid-2015 when it was posed. It has become so dated now that I think it should be closed. Any answers like this one above should probably be targeted to some newer version of the question that applies better to today's issues. I don't currently have such a question, myself. Nov 20, 2017 at 22:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.