0

I know this has come up a million times, but apparently not with .NET Core using System.Data.Odbc.

With TLS 1.0 turned of in the registry, I get an error:

{System.Data.Odbc.OdbcException (0x80131937): ERROR [08001] [Microsoft][ODBC SQL Server Driver][DBNETLIB]SSL Security error

ERROR [01000] [Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionOpen (SECDoClientHandshake()).

I get that error when running the ASP.NET Core site on the server that hosts SQL Server, but also using a dev machine on a Windows 10 client, connecting to the remote SQL Server.

SSMS runs and connects fine both on the server and on the client. When I switch on TLS 1.0 support, and restart SQL Server, the site runs fine on both the server and the client. (No need to reboot to see the difference).

To be sure I have enabled the FIPS support, even though I read somewhere that this is no longer needed.

This is the configuration:

  • Windows Server 2016 (up to date)
  • SQL Server 2016 SP2 with the latest updates
  • Just to be sure, I also installed .NET 4.7 even though I don't use that.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server] "Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server] "DisabledByDefault"=dword:00000001

My suspicion is that the System.Data.Odbc for .NET Standard 2.0 does not support 1.2. I would love to get some help and pointers.

[EDIT]

This is what is installed, it should support TLS 1.2:

  • Microsoft SQL Server 2012 Native Client with version 11.4.7001.0
  • Microsoft ODBC Driver 17 for SQL Server with version 17.3.1.1
  • Microsoft ODBC Driver 11 for SQL Server with version 12.2.5543.11
  • Microsoft ODBC Driver 13 for SQL Server with version 14.0.1000.169
TallTed
  • 9,069
  • 2
  • 22
  • 37
Pieter van Kampen
  • 1,957
  • 17
  • 21
  • Why are you using ODBC from .NET? You will get better performance with the SqlClient managed provider and TLS 1.2 support too. – Dan Guzman Feb 23 '19 at 03:43
  • @Dan Guzman: perhaps possible, but that would mean quite a large code change as the SQL from ODBC is not compatible with that of SQLClient – Pieter van Kampen Feb 23 '19 at 10:57
  • The ODBC driver change is the short-term fix but I do suggest you consider moving to the managed provider for the long term. – Dan Guzman Feb 23 '19 at 11:12
  • @DanGuzman I did a limited test and indeed the SQLClient does work. Do you have any pointers where the performance differences or benefits of SQLClient are explained? By the way, I have the latests ODBC driver, (I think) so I don't know a short term fix yet – Pieter van Kampen Feb 23 '19 at 11:39
  • The performance difference between a managed and unmanaged provider in .NET will be most evident when consuming large result sets by avoiding the interop overhead. YMMV but I've observed ODBC is about 50% slower in client side processing. Maybe not noticeable with an OLTP workload. With SqlClient, you'll get updates with .NET without a separately installed driver and would avoid the TLS issue you currently have. – Dan Guzman Feb 23 '19 at 12:05
  • Post the error message you get with the latest driver. – Dan Guzman Feb 23 '19 at 12:05
  • Post your full ODBC connect string. Also post the full list of names (and DLLs) of these drivers, as seen in each of the [32-bit and 64-bit ODBC Administrators](http://wikis.openlinksw.com/UdaWikiWeb/Win32vs64OdbcAdmin). I think your connection is not using the driver you're expecting. – TallTed Feb 24 '19 at 01:59

1 Answers1

-1

System.Data.Odbc is not the issue; [Microsoft][ODBC SQL Server Driver][DBNETLIB] is.

The solution is to get (or confirm you're using) a more recent ODBC Driver for SQL Server, from Microsoft or from my employer or from another vendor...

TallTed
  • 9,069
  • 2
  • 22
  • 37