Repository navigation
[SQL Server 2005] System.Data.SqlClient: pre-login fails with SSL error even with Encryption=false #24
Description
Activity
I'd say the second line in the exception stack trace,
System.Data.SqlClient.SNI.SslOverTdsStream.Read(...looks especially suspicious: it suggests SSL reader is used even though we told the client to not use it.Here's the capture file created by
tcpdumpof a sample session underEncrypt=false.The interesting thing is that the client is sending its PRELOGIN packet twice, and MS-TDS dissector in Wireshark considers the server's response to the first PRELOGIN packet as invalid.
cc @corivera
In the meantime I have converted the capture to a Network Monitor v2 format using the
editcaputility and inspected the generated capture in the Microsoft Network Monitor 3.4 (which has much better dissector for MS-TDS).Inspecting the capture in NM, I see:
- The dissector fails to properly parse the initial PRELOGIN packet we sent. Specifically it fails to parse the encryption option's data.
- The server's response packet explicitly has encryption option set to "off".
- Still, the second PRELOGIN packet we sent appears to contain the TLS 1.2 handshake, and the server apparently disconnects us after receiving it (supposedly failing to parse what should not have been a TLS handshake as "plain" payload).
Hence if we assume the NM's dissector is correct, its output might actually indicate several problems:
- We might be generating our PRELOGIN packet incorrectly.
- We fail to deal with the server telling us not to use encryption.
- The exception raised appears to be misleading as we did not actually read anything from the server after it disconnected us.
Here's that capture file.
@kostix Does this connectivity work from Windows using the same app?
Yes. Verified using
dotnet restore+dotnet runon a Windows 7 SP1 x64 using standalone SDK.Here are archived lockfiles from both projects (that one whose name starts with "win7" is from the Windows build, which works).
Yes. Verified using dotnet restore + dotnet run on a Windows 7 SP1 x64 using standalone SDK.
Is the Yes is for successful connection from Windows ?
We are looking into this.Yes, the connection works.
From the dump taken on that host using NM, it appears that the TLS session is still being used while authenticating, just it manages to happen OK on Windows.
There, the 192.168.2.145 is the client and .25 is the server.
Highlighted, is the server's PRELOGIN response packet indicating encryption turned off.
As you can see, what follows is the TLS-protected exchange.@saurabh500 @corivera any update on this? Are you planning to have a fix ready to review today or tomorrow?
@joshfree Currently trying to diagnose the problem.
@kostix Do you get this error on any other Linux distro, or is it limited to just Debian? If you haven't tested this, that's fine; just wondering. I'm actually getting generic TCP timeouts when connecting to SQL 2005 from Ubuntu (which is still unexpected).
- Sorry, I happen to use Debian whereever I run GNU/Linux systems. I have a couple of Wheezy (7.x) installations around but since corefx RC2 explicitly states it's not a supported platform I see little reason trying things there.
6 remaining items
Will the fix for this issue be present in core 1.1 ? @saurabh500
I've just hit this on centos 7. Any workarounds?
Any progress?
I am having the same problem connecting from an Amazon Linux AMI EC2 host to a Sql Server 2005 instance. I am using the mssql-cli client to test why my AWS Lamdba functions (C# .NET Core) were getting connection timeouts.
The packet captures look almost exactly the same as the original poster's - 2nd PRELOGIN request appears to attempt to send TLS/SSL payload and server responds by closing connection.
mssql-cli login attempts from Windows 10 host to this server succeed. SQL Server has encryption turned OFF.
I have never had this problem and have never upgraded SQL Operations Studio yet the same saved connections I have been using before now suddenly don't work anymore. I'm on macOS High Sierra.
Reacted by Abdelalim@sshinault Did you ever find a solution? I'm getting this from C# AWS lamba functions too.
@LandonCampbell No, we decided to upgrade to SQL Server 2008 R2 which works fine.
@sshinault Thanks, I appreciate the feedback.
As recently announced in the .NET Blog, focus on new SqlClient features an improvements is moving to the new Microsoft.Data.SqlClient package. For this reason, we are moving this issue to the new repo at https://github.com/dotnet/SqlClient. We will still use https://github.com/dotnet/corefx to track issues on other providers like System.Data.Odbc and System.Data.OleDB, and general ADO.NET and .NET data access issues.
Assuming all above issues are related to SQL Server 2005 and not a currently supported SQL version and closing this issue. Feel free to re-open if it is present against a currently supported version.
- added a commit that references this issue
on Jun 25, 2026

Platform : Debian 8 "Jessie"
Runtime : 1.0.0-preview1-002702,coreclr,x64,linux
System.Data.SqlClient : 4.1.0-rc2-24027
ConnectionString : Server=tcp:server.domain.lan,1433;User ID=XXXX;Password=XXXX;Encrypt=False"
An attempt to connect to a Microsoft SQL Server 2005 instance results in the following exception:
To me, the error looks as if the
Encrypt=falsejust does not get communicated properly in thePRELOGINpacket because the exception is the same no matter if I setEncrypttotrue(the default) orfalse.Adding
TrustServerCertificate=truewith theEncryptsetting enabled or disabled has no effect.The
Encryptsetting is parsed as if I specify an invalid value for it, I get an error about it.