TLS handshake failed on Debian buster

[r313pp]

Debian moved to new stable 10 (buster). oldstable is 9 (stretch).
I have trouble connecting to SQL Server on buster. I am getting this error:

(util.c:165):Changed query state from IDLE to DEAD
(util.c:319):tdserror(0x7ffc746a7de0, 0x55f2e26c8b60, 20017, 0)
(util.c:349):tdserror: client library returned TDS_INT_CANCEL(2)
(util.c:372):tdserror: returning TDS_INT_CANCEL(2)
(packet.c:542):Read attempt when state is TDS_DEAD
(tls.c:1028):handshake failed with -1 12 5
(tls.c:1069):handshake failed
(login.c:582):login packet rejected

With oldstable connection works as expected. And if you disable encryption everything works also.
The problem seems to be due OpenSSL update. buster has OpenSSL 1.1.1c 28 May 2019, stretch has OpenSSL 1.1.0k 28 May 2019. May be something to do with addition of TLS1.3 (ciphers list is not equal).
I've tested several versions of SQL Server and on stretch all of them working fine, on buster I have:

Debian Version	SQL Server Version	Result	Log
stretch	Microsoft SQL Server 2014 (SP2) (KB3171021) - 12.0.5000.0 (X64)	✅ works	stretch_2014SP2.log
stretch	Microsoft SQL Server 2017 (RTM-CU6) (KB4101464) - 14.0.3025.34 (X64)	✅ works	stretch_2017_RTM-CU6.log
stretch	Microsoft SQL Server 2017 (RTM-CU13) (KB4466404) - 14.0.3048.4 (X64)	✅ works	stretch_2017_RTM-CU13.log
buster	Microsoft SQL Server 2014 (SP2) (KB3171021) - 12.0.5000.0 (X64)	❌ not working	buster_2014SP2.log
buster	Microsoft SQL Server 2017 (RTM-CU6) (KB4101464) - 14.0.3025.34 (X64)	❌ not working	buster_2017_RTM-CU6.log
buster	Microsoft SQL Server 2017 (RTM-CU13) (KB4466404) - 14.0.3048.4 (X64)	✅ works	buster_2017_RTM-CU13.log

But I could not find what was fixed from CU6 to CU13 https://sqlserverbuilds.blogspot.com/#sql2017x.

To reproduce my problem I've made a repo. It requires docker.

git clone https://github.com/r313pp/freetds_handshake_failed
cd freetds_handshake_failed
./build buster
./build stretch
./run buster ./test -S my-server -U my_user -P my_password > buster.log
./run stretch ./test -S my-server -U my_user -P my_password > stretch.log

You actually don't need to specify user and password since problem occurs before login packets are sent.
Also you can modify .freetds.conf to set different options (openssl ciphers for example).
Then you can inspect *.log files. You can view my logs in table above.

You can get a console inside a container like this ./run buster bash or ./run stretch bash.

I've tried some different openssl ciphers, but haven't managed to find working one.

My problem is coming from that official python:3.7 docker image has moved to buster. I've switched to python:3.7-stretch while we update servers.

[freddy77]

Frediano Il giorno mar 23 lug 2019 alle ore 12:15 r313pp <notifications@github.com> ha scritto:

Debian moved to new stable 10 (buster). oldstable is 9 (stretch). I have trouble connecting to SQL Server on buster. I am getting this error: (util.c:165):Changed query state from IDLE to DEAD (util.c:319):tdserror(0x7ffc746a7de0, 0x55f2e26c8b60, 20017, 0) (util.c:349):tdserror: client library returned TDS_INT_CANCEL(2) (util.c:372):tdserror: returning TDS_INT_CANCEL(2) (packet.c:542):Read attempt when state is TDS_DEAD (tls.c:1028):handshake failed with -1 12 5 (tls.c:1069):handshake failed (login.c:582):login packet rejected With oldstable connection works as expected. And if you disable encryption everything works also. The problem seems to be due OpenSSL update. buster has OpenSSL 1.1.1c 28 May 2019, stretch has OpenSSL 1.1.0k 28 May 2019. May be something to do with addition of TLS1.3 <https://wiki.openssl.org/index.php/TLS1.3> (ciphers list is not equal).

Something similar happened in the past, OpenSSL added some field/record which MSSQL/Windows didn't like. There's a "openssl ciphers" option to try in freetds.conf. It's the same string used by SSL_set_cipher_list. But looks like you already tried it.

I've tested several versions of SQL Server and on stretch all of them working fine, on buster I have: Version Result Microsoft SQL Server 2014 (SP2) (KB3171021) - 12.0.5000.0 (X64) ❌ not working Microsoft SQL Server 2017 (RTM-CU6) (KB4101464) - 14.0.3025.34 (X64) ❌ not working Microsoft SQL Server 2017 (RTM-CU13) (KB4466404) - 14.0.3048.4 (X64) ✅ works But I could not find what was fixed from CU6 to CU13 https://sqlserverbuilds.blogspot.com/#sql2017x. To reproduce my problem I've made a repo. It requires docker. git clone https://github.com/r313pp/freetds_handshake_failed cd freetds_handshake_failed ./build buster ./build stretch ./run buster ./test -S my-server -U my_user -P my_password > buster.log ./run stretch ./test -S my-server -U my_user -P my_password > stretch.log You actually don't need to specify user and password since problem occurs before login packets are sent. Also you can modify .freetds.conf to set different options (openssl ciphers for example). Then you can inspect *.log files. Here is mine logs (I've deleted after login info since it's not relevant). buster_2014SP2.log <https://github.com/FreeTDS/freetds/files/3421689/buster_2014SP2.log> buster_2017_RTM-CU6.log <https://github.com/FreeTDS/freetds/files/3421690/buster_2017_RTM-CU6.log> buster_2017_RTM-CU13.log <https://github.com/FreeTDS/freetds/files/3421691/buster_2017_RTM-CU13.log> stretch_2014SP2.log <https://github.com/FreeTDS/freetds/files/3421692/stretch_2014SP2.log> stretch_2017_RTM-CU6.log <https://github.com/FreeTDS/freetds/files/3421693/stretch_2017_RTM-CU6.log> stretch_2017_RTM-CU13.log <https://github.com/FreeTDS/freetds/files/3421694/stretch_2017_RTM-CU13.log>

Mumble mumble... beside the list of extensions looks like the buster one contains the session ID! Maybe this is the issue. I don't know how to disable it using OpenSSL.

You can get a console inside a container like this ./run buster bash or ./run stretch bash. I've tried some different openssl ciphers, but haven't managed to find working one. My problem is coming from that official python:3.7 docker image has moved to buster. I've switched to python:3.7-stretch while we update servers. Thanks for all the attempts of reproducing it.

Frediano

[freddy77]

Il giorno mar 23 lug 2019 alle ore 14:24 Frediano Ziglio <freddy77@gmail.com> ha scritto:

Il giorno mar 23 lug 2019 alle ore 12:15 r313pp ***@***.***> ha scritto: > Debian moved to new stable 10 (buster). oldstable is 9 (stretch). > I have trouble connecting to SQL Server on buster. I am getting this > error: > > (util.c:165):Changed query state from IDLE to DEAD > > (util.c:319):tdserror(0x7ffc746a7de0, 0x55f2e26c8b60, 20017, 0) > > (util.c:349):tdserror: client library returned TDS_INT_CANCEL(2) > > (util.c:372):tdserror: returning TDS_INT_CANCEL(2) > > (packet.c:542):Read attempt when state is TDS_DEAD > > (tls.c:1028):handshake failed with -1 12 5 > > (tls.c:1069):handshake failed > > (login.c:582):login packet rejected > > > With oldstable connection works as expected. And if you disable > encryption everything works also. > The problem seems to be due OpenSSL update. buster has OpenSSL 1.1.1c 28 > May 2019, stretch has OpenSSL 1.1.0k 28 May 2019. May be something to do > with addition of TLS1.3 <https://wiki.openssl.org/index.php/TLS1.3> > (ciphers list is not equal). > Something similar happened in the past, OpenSSL added some field/record which MSSQL/Windows didn't like. There's a "openssl ciphers" option to try in freetds.conf. It's the same string used by SSL_set_cipher_list. But looks like you already tried it. > I've tested several versions of SQL Server and on stretch all of them > working fine, on buster I have: > Version Result > Microsoft SQL Server 2014 (SP2) (KB3171021) - 12.0.5000.0 (X64) ❌ not > working > Microsoft SQL Server 2017 (RTM-CU6) (KB4101464) - 14.0.3025.34 (X64) ❌ > not working > Microsoft SQL Server 2017 (RTM-CU13) (KB4466404) - 14.0.3048.4 (X64) ✅ > works > > But I could not find what was fixed from CU6 to CU13 > https://sqlserverbuilds.blogspot.com/#sql2017x. > > To reproduce my problem I've made a repo. It requires docker. > > git clone https://github.com/r313pp/freetds_handshake_failed > > cd freetds_handshake_failed > > ./build buster > > ./build stretch > > ./run buster ./test -S my-server -U my_user -P my_password > buster.log > > ./run stretch ./test -S my-server -U my_user -P my_password > stretch.log > > > You actually don't need to specify user and password since problem occurs > before login packets are sent. > Also you can modify .freetds.conf to set different options (openssl > ciphers for example). > Then you can inspect *.log files. > Here is mine logs (I've deleted after login info since it's not relevant). > buster_2014SP2.log > <https://github.com/FreeTDS/freetds/files/3421689/buster_2014SP2.log> > buster_2017_RTM-CU6.log > <https://github.com/FreeTDS/freetds/files/3421690/buster_2017_RTM-CU6.log> > buster_2017_RTM-CU13.log > <https://github.com/FreeTDS/freetds/files/3421691/buster_2017_RTM-CU13.log> > stretch_2014SP2.log > <https://github.com/FreeTDS/freetds/files/3421692/stretch_2014SP2.log> > stretch_2017_RTM-CU6.log > <https://github.com/FreeTDS/freetds/files/3421693/stretch_2017_RTM-CU6.log> > stretch_2017_RTM-CU13.log > <https://github.com/FreeTDS/freetds/files/3421694/stretch_2017_RTM-CU13.log> > Mumble mumble... beside the list of extensions looks like the buster one contains the session ID! Maybe this is the issue. I don't know how to disable it using OpenSSL.

Maybe SSL_CTX_set_session_cache_mode passing SSL_SESS_CACHE_OFF? Or SSL_set_session passing a NULL session?

…

You can get a console inside a container like this ./run buster bash or ./run > stretch bash. > > I've tried some different openssl ciphers, but haven't managed to find > working one. > > My problem is coming from that official python:3.7 docker image has > moved to buster. I've switched to python:3.7-stretch while we update > servers. > Thanks for all the attempts of reproducing it. Frediano

[freddy77]

Did you manage to try the changes I suggested?

[r313pp]

Yes, just tried with no effect.
Also tried SSL_CTX_set_options with SSL_OP_NO_TLSv1_3 - no success.

[r313pp]

SQL Server version seem like has nothing to do with this problem.
We updated CU6 to CU13 and problem stayed. Only difference is one is Enterprise and other is Development.
Working:

Microsoft SQL Server 2017 (RTM-CU13) (KB4466404) - 14.0.3048.4 (X64) 
	Nov 30 2018 12:57:58 
	Copyright (C) 2017 Microsoft Corporation
	Enterprise Edition: Core-based Licensing (64-bit) on Windows Server 2012 R2 Standard 6.3 <X64> (Build 9600: )

Not working:

Microsoft SQL Server 2017 (RTM-CU13) (KB4466404) - 14.0.3048.4 (X64) 
	Nov 30 2018 12:57:58 
	Copyright (C) 2017 Microsoft Corporation
	Developer Edition (64-bit) on Windows Server 2012 R2 Standard 6.3 <X64> (Build 9600: )

[freddy77]

It would be nice to understand which ciphers are accepted in case the connection succeeded. Can somebody do a network capture of a connection using Microsoft stack? Even a simple connection using control panel ODBC manager.

[r313pp]

Workaround found. On client side (where FreeTDS is installed) this must be done:

sed -i 's,^\(MinProtocol[ ]*=\).*,\1'TLSv1.0',g' /etc/ssl/openssl.cnf
sed -i 's,^\(CipherString[ ]*=\).*,\1'DEFAULT@SECLEVEL=1',g' /etc/ssl/openssl.cnf

or edit /etc/ssl/openssl.cnf manualy and change

[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=2

to

[system_default_sect]
MinProtocol = TLSv1.0
CipherString = DEFAULT@SECLEVEL=1

But this enables back TLSv1.0, the better way is to use TLSv1.2 on the server-side. I'll try to find how to do this and post here.

[kafran]

I was about to get crazy with this error trying to compile FreeTDS on a Docker Buster to use with ctds. I also noted if I use TDSVER=7.0 it works even with TLSv1.2. I also compiled FreeTDS with GnuTLS and it works. Is there any problem for using GnuTLS instead of openssl?

FreeTDS v1.1.33
SQL Server 2016 13.0.1601.5

[mckaygerhard]

@freddy77 added to faq a note about the #336 and concentrate in #299 to able to build with GnuTLS .. as i pointed M$ products are so crap as openssl are! GNUTLS is less complicated and does not cause a mess on every upgrade, may we have to merge issues with #299 and use GnuTLS that seems worked!

[juan-alencar-vagas]

I had to reinstall freedtds completely, so then it works.

sudo apt-get install wget
sudo apt-get install build-essential
sudo apt-get install libc6-dev

find latest version of FreeTDS ftp://ftp.freetds.org/pub/freetds/stable/

wget ftp://ftp.freetds.org/pub/freetds/stable/freetds-1.2.tar.gz
tar -xzf freetds-1.2.tar.gz
cd freetds-1.2
./configure --prefix=/usr/local --with-tdsver=7.3
sudo make
sudo make install