FreeTDS was auto-updated on 5/13/25 and it broke TLS on TDS 8.0

[bogdan.sh]

Hello there!

CloudLinux does not change the configuration of the EA-PHP packages; instead, it takes the original cPanel packages, recompiles them, and signs them with CloudLinux keys.

I've checked a couple of threads across the internet and really out of ideas what could be the case. However, here is what Gemini suggests, you should give it a try:

Most likely the temporary fix of downgrading to tds version = 7.4 and encryption = require works because:

• TDS 7.4 and earlier versions have a different, often more lenient, mechanism for negotiating encryption.
• Even when encryption is required with TDS 7.4, the handshake process or the range of acceptable ciphers/TLS versions might be broader or different from the strict requirements of TDS 8.0, allowing a successful connection.

To troubleshoot
Check Cipher Suites & Protocols with openssl s_client:
Use the openssl s_client command from your webserver to directly test the TLS connection to the MSSQL server. This bypasses FreeTDS and shows what OpenSSL itself can negotiate.

openssl s_client -connect <MSSQL_SERVER_IP>:1433 -tls1_2 -msg

# You can also try -tls1_1, -tls1_3 if applicable

Look for:

• The "Cipher :" line in the successful connection information.
• The list of "ClientHello" ciphers sent.
• Any error messages if it fails. This will help you see if your underlying OpenSSL can even agree on a cipher with the server.

[RKUK]

I posted this on the cpanel forum as I'm not really sure where is the best place to address this:

https://support.cpanel.net/hc/en-us/...al-integration
(Still pending approval so might not be visible immediately)

Here is a copy of the post:
I have a client site where there are some direct connections to their internal MSSQL database from their website for syncing data. Overnight between 5/13 and 5/14 the connection failed and it took me until yesterday to figure out the problem was on our end and not their end which isn't a great look for me.

Once I discovered it was not a network issue and realized it was a TLS handshake issue (took me longer than I'd like to admit to get this to actually write a debug log so I could understand what was happening), still could not understand why it was happening for quite some time and still unsure if the source of the issue was on our end or their end.

I messed around with this for several hours and then on a fluke my TSQL command line testing connected correctly. I saw in the debug log that for some reason the working connection used TDS version 7.4 and not 8.0 even though 8.0 is specified in the freetds.conf file for this server. I still do not understand why it did this, but I'm glad it did as it allowed me to get this "working" again.

My temporary fix at this point was to downgrade the configuration to use 7.4 and set the encryption setting to "require" which does still encrypt the connection (verified via tcpdump).

All this being said, I would like to know what changed in this update and why the 8.0 protocol no longer works, and if there is something I need to do to make it work again, or if this is some kind of bug that got introduced in this update (update log below).

Here is a debug log of the TLS handshake failure when using 8.0:

10:49:00.698263 560925 (log.c:187):Starting log file for FreeTDS 1.5.1
on 2025-05-16 10:49:00 with debug flags 0xffff.
10:49:00.698278 560925 (iconv.c:371):tds_iconv_open(0x2b5cad0, UTF-8, 1)
10:49:00.698341 560925 (iconv.c:202):local name for ISO-8859-1 is ISO-8859-1
10:49:00.698345 560925 (iconv.c:202):local name for UTF-8 is UTF-8
10:49:00.698347 560925 (iconv.c:202):local name for UCS-2LE is UCS-2LE
10:49:00.698349 560925 (iconv.c:202):local name for UCS-2BE is UCS-2BE
10:49:00.698362 560925 (iconv.c:390):setting up conversions for client charset "UTF-8"
10:49:00.698364 560925 (iconv.c:392):preparing iconv for "UTF-8" <-> "UCS-2LE" conversion
10:49:00.698414 560925 (iconv.c:431):tds_iconv_open: done
10:49:00.698417 560925 (net.c:369):Connecting with protocol version 8.0
10:49:00.698429 560925 (net.c:295):Connecting to <IP REMOVED> port 1433
10:49:00.698473 560925 (net.c:317):tds_setup_socket: connect(2) returned "Operation now in progress"
10:49:00.737696 560925 (net.c:506):tds_open_socket() succeeded
10:49:00.744689 560925 (tls.c:1091):setting default openssl cipher to:HIGH:!SSLv2:!aNULL:-DH
10:49:00.744839 560925 (tls.c:190):in tds_push_func
10:49:00.744850 560925 (tls.c:171):in tds_pull_func
10:49:01.030337 560925 (util.c:179):Changed query state from IDLE to DEAD
10:49:01.030345 560925 (util.c:333):tdserror(0x2b5a8a0, 0x2b5cec0, 20017, 0)
10:49:01.030349 560925 (odbc.c:2527):msgno 20017 20003
10:49:01.030353 560925 (util.c:363):tdserror: client library returned TDS_INT_CANCEL(2)
10:49:01.030356 560925 (util.c:386):tdserror: returning TDS_INT_CANCEL(2)
10:49:01.030360 560925 (tls.c:1119):handshake failed with -1 12 5
10:49:01.030791 560925 (tls.c:1168):handshake failed
10:49:01.030795 560925 (login.c:693):login packet rejected
10:49:01.030798 560925 (util.c:333):tdserror(0x2b5a8a0, 0x2b5cec0, 20002, 0)
10:49:01.030800 560925 (odbc.c:2527):msgno 20002 20003
10:49:01.030803 560925 (util.c:363):tdserror: client library returned TDS_INT_CANCEL(2)
10:49:01.030805 560925 (util.c:386):tdserror: returning TDS_INT_CANCEL(2)
10:49:01.030808 560925 (mem.c:665):tds_free_all_results()
10:49:01.030862 560925 (error.c:417):odbc_errs_add: "Unable to connect to data source"
10:49:01.030866 560925 (error_export.h:107):SQLError((nil), 0x2b5a900, (nil), 0x7ffddef6c82a, 0x7ffddef6c410, 0x7ffddef6cb30, 513, 0x7ffddef6c40a)
10:49:01.030870 560925 (error.c:563):SQLGetDiagRec: "[FreeTDS][SQL Server]Unexpected EOF from the server"
10:49:01.031044 560925 (error_export.h:107):SQLError((nil), 0x2b5a900, (nil), 0x7ffddef6c82a, 0x7ffddef6c410, 0x7ffddef6cb30, 513, 0x7ffddef6c40a)
10:49:01.031047 560925 (error.c:563):SQLGetDiagRec: "[FreeTDS][SQL Server]TDS server connection failed"
10:49:01.031052 560925 (error_export.h:107):SQLError((nil), 0x2b5a900, (nil), 0x7ffddef6c82a, 0x7ffddef6c410, 0x7ffddef6cb30, 513, 0x7ffddef6c40a)
10:49:01.031054 560925 (error.c:563):SQLGetDiagRec: "[FreeTDS][SQL Server]Unable to connect to data source"
10:49:01.031059 560925 (error_export.h:107):SQLError((nil), 0x2b5a900, (nil), 0x7ffddef6c82a, 0x7ffddef6c410, 0x7ffddef6cb30, 513, 0x7ffddef6c40a)
10:49:01.031061 560925 (odbc.c:4295):SQLFreeHandle(2, 0x2b5a900)
10:49:01.031064 560925 (odbc.c:4321):odbc_SQLFreeConnect(0x2b5a900)
10:49:01.031066 560925 (bcp.c:685):_bcp_free_storage(0x2b5a900)
10:49:01.031068 560925 (odbc.c:4295):SQLFreeHandle(1, 0x2b5a810)
10:49:01.031078 560925 (odbc.c:4368):odbc_SQLFreeEnv(0x2b5a810)

Here is the update/version history for the two freetds packages on my system:

[root@host updatelogs]# yum history ea-freetds
This system is receiving updates from CloudLinux Network server.
ID | Command line | Date and time | Action(s) | Altered
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
629 | --assumeyes --color=never --config /etc/yum.conf update --enablerepo=cloudlinux-PowerTools --enablerepo=epel | 2025-05-13 10:32 | I, U | 622 E<
113 | --assumeyes --color=never --config /etc/yum.conf update --enablerepo=cloudlinux-PowerTools --enablerepo=epel | 2023-12-15 05:34 | I, U | 163 ><
86 | --assumeyes --color=never --config /etc/yum.conf update --enablerepo=cloudlinux-PowerTools --enablerepo=epel | 2023-11-15 05:33 | Upgrade | 42 ><
67 | -y shell /tmp/LMuKg3qXgS | 2023-11-03 19:36 | E, I, U | 145 >E
[root@host updatelogs]# yum history ea-freetds-libs
This system is receiving updates from CloudLinux Network server.
ID | Command line | Date and time | Action(s) | Altered
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
629 | --assumeyes --color=never --config /etc/yum.conf update --enablerepo=cloudlinux-PowerTools --enablerepo=epel | 2025-05-13 10:32 | I, U | 622 E<
113 | --assumeyes --color=never --config /etc/yum.conf update --enablerepo=cloudlinux-PowerTools --enablerepo=epel | 2023-12-15 05:34 | I, U | 163 ><
86 | --assumeyes --color=never --config /etc/yum.conf update --enablerepo=cloudlinux-PowerTools --enablerepo=epel | 2023-11-15 05:33 | Upgrade | 42 ><
67 | -y shell /tmp/LMuKg3qXgS