Unencrypted connection to SQL Server throws handshake error

Question

I have a .NET 6 service running in a container (based on the mcr.microsoft.com/dotnet/aspnet:6.0-focal image). When my service needs to talk to the SQL Server database, I must set SECLEVEL=1 in my OpenSSL config. I run the following when creating the container (taken from this github issue: https://github.com/dotnet/SqlClient/issues/776#issuecomment-825418533)

RUN sed -i '1i openssl_conf = default_conf' /etc/ssl/openssl.cnf && echo "\n[ default_conf ]\nssl_conf = ssl_sect\n[ssl_sect]\nsystem_default = system_default_sect\n[system_default_sect]\nMinProtocol = TLSv1.2\nCipherString = DEFAULT:@SECLEVEL=1" >> /etc/ssl/openssl.cnf

If I don't, I get this 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)

But... my connection string has not set anything about encrypt or anything else that indicates that I must make an encrypted connection. And when I look at EF Core 6 or less, Encrypt=False is the default. So if you don't do anything explicit, I assume that the connection is not encrypted.

My connection string looks like this

Server=123,456;Database=123;User ID=123;PWD=123;multipleactiveresultsets=True;TrustServerCertificate=True;

On the .NET side I'm using Microsoft.EntityFrameworkCore.SqlServer 6.0.13, which has a dependency on Microsoft.Data.SqlCliet 2.1.4. Both of these has encrypt=false as default for the connection strings.

And that's where I'm unable to understand what happens.

If the connection is not encrypted, why do I have to set SECLEVEL=1 to avoid handshake errors? Why does a handshake even happen?

Answer 1

If the SQL Server you are connecting to is configured with force encryption, TLS/SSL will be used for all communication regardless of whether the client requests encryption or not.

Even if encryption is not required by client or server, login packets for the credential exchange are still encrypted. The setup needed to do so occurs as part of the pre-login handshake as described in this answer. This introduces the TLS/SSL requirement.