最近半路接手了一个系统的优化需求，这个系统有个遗留问题还没解决，随着新需求的上线，系统正式开放使用，这个遗留问题也必须解决。
这个系统大概是下面这样的，支持录入各种数据源的信息（ip、端口、数据库种类、账号密码等）：
录入完成后，可以查看这些数据源中的表、表的ddl、表中的列（列名、类型及注释等），也可以查看各个表中的数据。
其中一个数据源，是sql server 2008版本，总是连接失败，更别提获取这个db中的表了。
错误堆栈如下：
在我做新需求的时候，我之前的同事A已经处理过这个问题。这个问题只在线上出现，因为开发测试环境压根没有这么老的数据库版本，在开发测试环境申请一台windows服务器来安装一个这样的老版本数据库，也比较麻烦；所以，同事A在处理的时候，基本是网上查到修改的办法后，直接弄到线上去试试能不能解决。
之前改过两次，第一次是这样：
1、参考附件脚本《配置文件java.security》，修改/usr/local/jdk/bin/java/java.security中的配置项jdk.tls.disabledAlgorithms。
修改内容：删除jdk.tls.disabledAlgorithms配置项的“TLSv1, TLSv1.1”，替换成“DHE”
简单解释下这部分的修改，从前文中的错误堆栈来看，这个问题是和ssl有关系的，我之前猜想的就是，这个sql server和mysql一样，支持使用tls加密传输，保护数据安全；但是，可能sql server 2008版本太老了，不支持tls 1.2/1.3这些，只能使用tls1.1/tls1.0等，但是呢，jdk认为使用tls1.1/1.0不够安全，默认是禁用了的，所以，只要把这个禁用tls1.1/tls1.0的配置给改改，允许jdk使用tls1.1/tls1.0，不就可以连接sql server 2008了吗？
但是，遗憾的是，这个改动之前已经上线试过了，没有生效，还是报错。
另外，在我做新需求的时候，同事A又试了一个改动，把驱动版本升级了下，大家知道java都是使用jdbc去连接数据源的，各个厂商会实现jdbc，之前呢，使用的是sqlserver的4.0版本的驱动，这把，直接弄到了8.4.1，准备搞上去再试试：
我了解到这个情况后，因为需求也比较赶，就没想花大力气来搞这个bug，我们都是内网服务器之间调用，这个加密传输，我感觉不是必要，直接弄成不加密不就行了吗？
我找了下代码，里面有拼接jdbc url的代码：
那直接去掉这个encrypt=true;trustServerCertificate=true，去掉后，本地测试了下连接sql server数据库（不是2008版本），用wireshark抓包看了下，发现客户端发给数据库（sql server常用1433端口）的报文里，还是说加密是开启的：
行吧，我查了下，原来不指定encrypt属性，默认就是true，那我手动指定成false得了。
又抓包看了下，这次有了变化，客户端发过去的报文是说，不使用加密：
服务端返回报文也说，不加密：
但是，我在后续的报文里，发现还是部分加密了的：
这就有得难以理解了。
所以这时候的思路就是，看看为什么源码里还会加密传输，那只能debug了，看看是不是还有其他选项在控制这块，后面找到如下代码：
在上图中，先是三次握手，再是prelogin（就是前文抓包看到的那部分，如：Encryption: Encryption is available but off (0)）,再下来呢，有个if，如果满足这个if，就会开启SSL，此时，就会导致发出去的报文是ssl的，也就是说，只要走了这个if，我们就绕不开ssl，就规避不了这个bug。
那我们看看，怎么绕开这个if吧。
这个if中，左边是个常量，ENCRYPT_NOT_SUP表示不支持加密，
右边是个变量，初始化的时候是：
private byte negotiatedEncryptionLevel = TDS.ENCRYPT_INVALID;
后续，什么地方会修改这个变量呢，是在prelogin部分，在处理数据库返回的prelogin响应报文时：
这里，2812行，是直接取响应报文中的值，也就是说，以数据库服务端的为准。
还记得，服务端一般是返回如下值：0。
那这样的话，就会导致那个if条件为true：
这块就有点难办了，这个值是服务端返回的，除非数据库返回ENCRYPT_NOT_SUP，表示不支持加密，否则，这个加密是跑不掉了。但我没太想过要让数据库去改这个配置，毕竟这个库，说是客户端还不少，我不可能去动它，影响太大，可能到时候导致别的客户端要改造。
还有个方向，是通过客户端的传参，去影响服务端的返回值，比如客户端传一个不支持加密，看看服务端的返回值。
但，比较遗憾的是，客户端驱动定死了，只能传下面这两个值，要么ENCRYPT_ON，要么ENCRYPT_OFF：
当时，我的想法是，把这个if条件改一下，改成:
if (TDS.ENCRYPT_ON == negotiatedEncryptionLevel){
tdsChannel.enableSSL(serverInfo.getServerName(), serverInfo.getPortNumber());
}
其实，按我这会的想法，改下面这个地方也不错，想办法传ENCRYPT_NOT_SUP给服务端：
requestedEncryptionLevel = isBooleanPropertyOn(sPropKey, sPropValue) ? TDS.ENCRYPT_ON : TDS.ENCRYPT_OFF;
如何才能修改驱动包的代码呢，改是改不了，但是可以想办法覆盖，方法就是在项目中建同包名同类名的java文件（内容直接从源码文件拷贝），然后修改其中的部分代码即可。
但这次有点意思的是，遇到个以前没见过的问题，报如下错误：
java.lang.SecurityException: signer information does not match signer information
删除的方式，可以直接用压缩软件打开，删除里面的这两个文件即可，另存为即可。然后把改后的jar包发布到私服（可以修改下坐标），或者是使用maven的如下方式：
最终成功绕过enableSSL了，抓包发现，客户端确实没对包进行加密了，但是，服务端不返回任何报文了。我理解的是，服务端当初在进行prelogin协商时，返回的加密选项是：ENCRYPT_OFF，这个按正常流程，后续就是需要加密的，我们现在强行改了客户端源码，导致服务端陷入了迷思：wtf，客户端怎么回事，怎么没加密，这个客户端有问题？行吧，我不返回了。
最终，我还是放弃了这条路。因为，我上网查了下这个encrypt选项。
https://learn.microsoft.com/zh-cn/sql/connect/jdbc/understanding-ssl-support?view=sql-server-ver16
原来，加密分为两个部分，第一个部分是登录部分，建立连接时，会传输用户名密码，我当时发现：在我上面强行改了客户端驱动，收不到服务端响应时，进行了抓包，发现我可以看到明文密码，当时我也有点惊讶，也反应过来了，难怪要弄ssl加密呢；第二个部分是，后续的数据的加密，如传输的sql语句和执行结果。
当encrypt为true时，两个部分都会加密；而当encrypt为false时，登录部分还是会加密，而数据部分不会加密。
所以，不管怎么说，登录部分总是要加密的，所以我还是不要挑战这条路了，毕竟这是协议规定好了的。
最终，把修改源码部分，全都回退了。最终的jdbc url选项如下，驱动版本也保留着
;encrypt=false;trustServerCertificate=true;
<dependency>
<groupId>com.microsoft.sqlserver</groupId>
<artifactId>mssql-jdbc</artifactId>
<version>8.4.1.jre8</version>
</dependency>
说白了，ssl问题依然会有（毕竟encrypt=false，登录部分还是要走ssl），但是，我们可以想办法把ssl过程中的日志打印出来：
System.setProperty("javax.net.debug","ssl:handshake:verbose");
这个呢，会打印ssl过程中的细节（注意，是打印到标准输出的，日志文件里没有，要看看启动java进程时，把标准输出重定向到哪里去了，不能是 > /dev/null这种），类似下面这种，到时候我们上线了再看看日志情况吧：
这个问题，现在说白了，就是客户端发了ssl握手消息给服务端，正常来说，服务端是要响应的，像下面这样，返回server hello这个报文，其中包含选定的ssl加密套件、服务端证书链等信息：
然后我预期的是，上线后，这个ssl日志能把服务端报错的原因打印出来，结果并没有。
直接就是说，服务端关闭了连接，终止握手：
从后来我找运维抓的包也能看出来，服务端发了tcp关闭的报文：
此时，有点陷入僵局了。客户端没日志，网络报文也看不出来，那意思是只能看看服务端有没有日志了吧。
然后去找了dba，我现场演示了下，他看了数据库端的日志文件：啥都没有。
他给了我两个方案，一个是这个库太老，后续会复制一个新库出来，这个要等；再一个是，这个库也有其他的项目在用，也是java客户端的，他说帮我问下相关同事。
然后后续我单独加了那个同事，了解了下，他们用的驱动版本是7.4.1，我们目前线上是8.4.1:
<dependency>
<groupId>com.microsoft.sqlserver</groupId>
<artifactId>mssql-jdbc</artifactId>
<version>7.4.1.jre8</version>
</dependency>
然后，jdbc的url是这样：
最终我们的方向是，换不同版本的驱动看一下，先试上面这个7.4.1.jre8版本。因为之前我也查到过资料，就是xx版本的数据库，需要xx版本的驱动。
从图里能看出来，sql server 2008，需要7.2版本的驱动。我们之前的8.4.1，肯定是高了；其实看上图，7.4也高了，但不知道人家项目为啥能行，就也试试呗。
写了个类来测试：
执行方式就是把jar和class放到同一目录下执行：
[root@news-center-app ~]# ll DbConnectTest.class mssql-jdbc-7.4.1.jre8.jar
-rw-rw-rw- 1 root root 1631 Dec 30 15:30 DbConnectTest.class
-rw-rw-rw- 1 root root 1209660 Dec 30 15:16 mssql-jdbc-7.4.1.jre8.jar
[root@news-center-app ~]# java -classpath .:./mssql-jdbc-7.4.1.jre8.jar DbConnectTest "jdbc:sqlserver://1.1.1.1:1433;databaseName=xxx;encrypt=false;trustServerCertificate=true" zhangsan xxx
这样呢，方便我们替换驱动的jar包。
结果呢，运维说必须走流程才能这么玩，理由就是不能在生产上做测试，battle了半天，后面还是提流程了（正好有个小需求又要上，就把这个工具一起弄上去了）。
上线的时候，我们顺便就把之前的驱动版本从8.4.1.jre8改成了7.4.1.jre8，也包括这个小工具。
上线后，以为这次肯定能行，结果，还是报一样的错误，此时正值周五快下班的时候，我无语了：就不能早点解决了这个bug，好好过个周末，不然还牵挂着它。
结果我回家路上，运维在群里说，bug可以了，他上网找了下文章：
https://blog.csdn.net/zhujun300/article/details/141434867
还是修改jdk的java.security文件，这次又把另一个被禁用的给去掉了：3DES_EDE_CBC. (我在开头说，同事A之前就改过一次，但是去的是tls1.1/tls1.0，没去这个3DES_EDE_CBC)。
然后，就好了。
行吧，还是能好好过周末的。
网上翻了很多资料，没找到讲这块原理的。我自己本地试验了下，在去掉这个3DES_EDE_CBC前，记录了打印的ssl日志；在去掉后，又记录了下。
对比如下，可以看到，去掉后，握手消息中多了很多加密套件（其中都包含了3DES_EDE_CBC这个加密算法）：
那这样的话，我们可以认为，线上那个库，应该是不支持客户端发送出去的所有加密套件，才把ssl握手终止了。
而加上3DES_EDE_CBC后，多了一些加密套件，而这些套件，正好服务端就支持，所以就可以了。
当然，具体选择了哪个加密套件，可能得下周上班了再找运维看看日志或者抓个包瞧瞧才知道。
这次呢，我也学会了一个新技能，由于ssl握手消息是封装在其他协议（TDS）里面的，在wireshark中都没法看。
上面蓝色部分就是握手消息，但看不了，要知道握手的具体细节，非得看ssl日志才行，这个让人有点不爽。
我上网找了下，还真找到个网站：
https://williamlieurance.com/tls-handshake-parser/
只要把十六进制流复制进去，就能解析ssl。
对我来说，算是不小的一个收获。
一开始，对这块不理解，以为ssl加密相关能力是sql server 2008这个软件提供的（对windows服务器太不了解了），但后来查了些资料发现，ssl加密相关能力是操作系统提供的；像是linux呢，一般就是安装了openssl，其他软件都是复用openssl的能力。
而sql server 2008,当时查了下版本：
Microsoft SQL Server 2008 (SP1) - 10.0.2531.0 (X64) Mar 29 2009 10:11:52 Copyright (c) 1988-2008 Microsoft Corporation Enterprise Edition (64-bit) on Windows NT 5.2 <X64> (Build 3790: Service Pack 2) (VM)
没细问windows服务器的版本，但我们从上述也能看出来：
windows服务器版本其实就是：Windows NT 5.2 (Build 3790: Service Pack 2)
这个服务器，搜索了下，其实是：win server 2003版本。
难怪了，这个操作系统版本太低了，估计就是很多ssl套件都不支持。
那么，我们如何查看一个windows电脑，支持哪些加密套件呢？
有以下几种方式：
使用 PowerShell：以管理员身份运行 PowerShell，输入Get-TlsCipherSuite命令，可列出当前系统上配置的 TLS/SSL 加密套件以及它们的启用状态等信息。
这边下载了一个软件：https://www.nartac.com/Products/IISCrypto/Download
可以大概看到ssl中涉及的几个部分：传输协议、加密算法、hash算法、秘钥交换算法。
通过上述几个部分，组成了各种各样的ssl套件：
https://learn.microsoft.com/en-us/windows/win32/secauthn/schannel-cipher-suites-in-windows-vista
我猜测这个问题应该是比较好复现的，只是苦于没有环境，然后就想着在本机装一个，没想到，就这也踩了好久的坑。
安装sql server 2008，依赖.net framework 3.5这个运行环境，我是win10系统。网上的方法分两类，在线安装和离线安装，整个.net framework 3.5包有100多m，在线安装，我这边反正不行，不只是网络的问题，好像在线安装是需要一个service正常运行才可以：windows update。
相信很多人，当初为了禁用windows的升级，可能把这个service都删掉了。
可能也正是因为这样，我甚至离线安装也是失败的。
我也附上几个链接吧，万一大家可以呢：
https://mp.weixin.qq.com/s/y0sZz8wtLtcPQM0sI8DHmQ
https://mp.weixin.qq.com/s/_unsXuBLH1JjtsprKYjSWw
https://mp.weixin.qq.com/s/4FtoTMF3L_hDAXGu_GgOdA
试这些的时候，也可以先看下官方帮助文档：
https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/enable-or-disable-windows-features-using-dism?view=windows-11
C:\WINDOWS\system32>dism /online /?
dism /online /Enable-Feature /?
dism /online /Add-Package /?
最终，我用上述这些方法也没成功，后来是按照如下文章来解决的：
https://blog.csdn.net/Roeluo/article/details/144692042
当然，这个.net framework 3.5装上了，并不影响我的sql server 2008安装失败，当然，现在bug都解决了，有空再弄吧。
https://blog.csdn.net/wpf416533938/article/details/128573683
https://blog.csdn.net/tanhongwei1994/article/details/84957254
https://www.reddit.com/r/sysadmin/comments/u6grqv/very_legacy_ssl_problem_on_server_2003yep_it/
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。