Azuredatastudio: Pre-login SSL/TLS handshake error

Created on 3 Apr 2018  路  21Comments  路  Source: microsoft/azuredatastudio

  • SQL Operations Studio Version: 0.27.3

Steps to Reproduce:

  1. Have a SQL instance in AWS RDS running 11.00.6020.0.v1 using SSL provided by RDS (rds-ca-2015)
  2. Create connection from Mac 10.13.4 High Sierra to MS SQL instance
  3. User is a SQL login with default connection options.
  4. Click connect - receive error pop up with the following error
A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: SSL Provider, error: 31 - Encryption(ssl/tls) handshake failed)

I have connected using this connection configuration before without issue. The only things I can remember changing between this working and not, are the upgrade to MacOS 10.13.4. Have also re-installed SQL Operations Studio, but this hasn't resolved the issue.

Stacktrace gist - from Error box 'Copy Details'

I noticed that dotnet/corefx has had a similar issue with the same error message raised in the last few days - https://github.com/dotnet/corefx/issues/28652 I wondered if it could be related?

Bug

Most helpful comment

I'm seeing the same problem. Any update on the resolution timeline?

All 21 comments

@kburtram looks like this is due to some breaking change in macOS 10.13.4 - the corefx team are targeting a release on 4/17. If this is affecting all Windows Authentication on macOS we'll likely need to assess how quickly we can pick this up and ship the fix.

@nm-harry thanks for raising this. Since we depend on .Net Core this will indeed affect us.

@kevcunnane the issue mentions the error occurs for a user with SQL Login. I didn't see where the scope of this is limited Windows Authentication. Is that implied through the netfx issue's context?

You鈥檙e correct, I misread this. It鈥檚 even higher priority given this - anyone who upgrades may be broken. We can dog food the fix and pick up as soon as it鈥檚 out?

I'm seeing the same problem. Any update on the resolution timeline?

@lhector2 it looks like the .Net Core issue says their release is targeting 4/17. Once that's out we should have an insiders build with the fix within a day or so. Our next stable build is targeting 4/24.

I will look into using the .Net Core 2.1 daily build to get out an updated insiders build possible earlier than 4/17.

I've posted a test build which includes the latest changes in master and a SQL Tools Service built with the latest daily build of .Net Core 2.1 SDK which contains a fix for dotnet/corefx#28652.

~Please let me know if the issue still repros with this build https://sqlopsbuilds.blob.core.windows.net/stage/sqlops-macos-0.28.3-netcore2.1.zip.~ (working on a new build)

@kburtram I still experience this problem with the above build :/
Stacktrace gist - from Error box 'Copy Details'

@holyszack thanks for confirming. Let me try to figure out why this build didn't pick up the fix.

~@holyszack I've posted an updated build at https://sqlopsbuilds.blob.core.windows.net/stage/sqlops-macos-0.28.3-netcore2.1-2.zip. If you have a chance please check if this build works.~ (apparently this build doesn't resolve the issue either)

I upgraded my macOS to 10.13.4 and wasn't able to repro. So I can't test internally.

@kburtram I tried this new build on MacOS 10.13.4 and I still facing same issue.

@sunildparte thanks for verifying. Unfortunately without a repro it's a bit tricky to valid the fix. I'll go back again and see why the preview .Net Core 2.1 bits aren't getting included in the package, or if I have the wrong SDK version. I think the official .Net Core 2.1 SDK will be out on 4/17, but it would be great to validate that the SDK changes actually resolve this issue before then.

I'll try to get an update test build out later tonight or tomorrow, once I figure out what's going on. Thanks again!

@sunildparte @holyszack I've posted an updated test build at https://sqlopsbuilds.blob.core.windows.net/stage/sqlops-macos-0.28.3-netcore2.1-3.zip.

I've confirmed this package contains today's .Net Core daily build "Microsoft.NETCore.App": "2.1.0-preview3-26411-06" which that version of the SDK contains 2.1.0-preview2-30475 runtime.

According to https://github.com/dotnet/corefx/issues/28652 "The fix went into master on 31 March, so any 2.1.0-preview2-2640* build should have it."

If possible, please let me know if the issue repros with this build.

I can confirm that this latest build does resolve the connection issue. I haven't tested a ton of stuff yet, but basic queries work fine.

@kburtram your build solved connection problem. Thanks.

Thanks for these preview builds. This build solves the issue.

Just wanted to chime in that I ran into this issue tonight (2018-04-14 11:03 PM EDT) and the preview build fixed it. Thanks @kburtram!

Thanks for confirming the test build resolves the issue. We'll figure out the best way to include this fix in the next published build. Hopefully, if the final .Net Core 2.1 SDK update publishes tomorrow as planned we can just pick that up.

The latest insiders build should contain the fix for this bug at https://github.com/Microsoft/sqlopsstudio/releases/tag/0.28.4.

This build contains the .Net Core 2.1-built SQL Tools Service that we plan to ship in the April Public Preview this Wednesday.

The April Public Preview build should contain the fix for this issue. So I'm close now. Please reactive the issue persists in the most recent build.

I am seeing this consistently on a SQLServer instance running in a Container. I get it from both Azure Studio on Linux and Windows.

System.Data.SqlClient.SqlException (0x80131904): A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.) ---> System.ComponentModel.Win32Exception (10054): An existing connection was forcibly closed by the remote host
at System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, SqlCredential credential, Object providerInfo, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance, SqlConnectionString userConnectionOptions, SessionData reconnectSessionData, Boolean applyTransientFaultHandling)
at System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection, DbConnectionOptions userOptions)
at System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(DbConnection owningConnection, DbConnectionPoolGroup poolGroup, DbConnectionOptions userOptions)
at System.Data.ProviderBase.DbConnectionFactory.<>c__DisplayClass40_0.b__1(Task1 _) at System.Threading.Tasks.ContinuationResultTaskFromResultTask2.InnerInvoke()
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location where exception was thrown ---
at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot)
--- End of stack trace from previous location where exception was thrown ---
at Microsoft.SqlTools.ServiceLayer.Connection.ReliableConnection.ReliableSqlConnection.<>c__DisplayClass28_0.<b__0>d.MoveNext() in D:\a\1\s\src\Microsoft.SqlTools.ServiceLayer\Connection\ReliableConnection\ReliableSqlConnection.cs:line 298
--- End of stack trace from previous location where exception was thrown ---
at Microsoft.SqlTools.ServiceLayer.Connection.ConnectionService.TryOpenConnection(ConnectionInfo connectionInfo, ConnectParams connectionParams) in D:\a\1\s\src\Microsoft.SqlTools.ServiceLayer\Connection\ConnectionService.cs:line 543
ClientConnectionId:cf416ed7-dceb-4c82-9ce2-fd5ab3c39d38
Error Number:10054,State:0,Class:20

I'm leaving this here in case anyone else runs into the same problem I just ran into with the following setup:

  • macOS Sierra 10.12.6
  • Docker image microsoft/mssql-server-linux
  • Docker 18.09.0, build 4d60db4
  • Azure Data Studio 1.3.9

The problem was that I attempted connecting to the Docker container's :1434 port and not :1433, as such:

ports: 
- "1433:1434"

Changing this to 1433 on both sides fixed the problem:

ports: 
- "1433:1433"
Was this page helpful?
0 / 5 - 0 ratings

Related issues

Ungerfall picture Ungerfall  路  3Comments

jacobzed picture jacobzed  路  3Comments

kburtram picture kburtram  路  3Comments

kburtram picture kburtram  路  3Comments

squillace picture squillace  路  3Comments