Java 1.8连接SQL Server 2008 R2启用加密后无法执行查询

使用Java 1.8连接仅支持TLSv1的SQL Server 2008 R2（无法更换），通过ms-sql jdbc连接并执行查询，配置SQLServerDataSource时通过setEncrypt()控制加密：

• 关闭加密：连接成功（SQL Server端查询SELECT * FROM sys.dm_exec_connections显示encrypt_option = FALSE），可正常执行查询获取数据；
• 开启加密：连接成功（SQL Server端显示encrypt_option = TRUE），但执行executeQuery()时抛出错误：

  com.microsoft.sqlserver.jdbc.SQLServerException: SQL Server did not return a response. The connection has been closed.

已尝试的操作：

• 测试多个mssql-jdbc版本：6.2.2.jre8、8.2.2.jre8、12.8.0.jre8，均出现相同问题；
• 通过JDBC配置（dataSource.setSSLProtocol("TLSv1")）或修改java.security调整SSL协议，无效果。

疑问：该现象原因是什么？为何仅在查询执行阶段失败，而非连接阶段？

核心原因 #

这个问题本质是Java 1.8的TLSv1实现与SQL Server 2008 R2的加密通信逻辑在数据传输阶段不兼容，具体两点：

1. TLS会话复用冲突：SQL Server 2008 R2的TLSv1实现不支持Java 1.8默认启用的TLS会话复用机制，连接建立后执行查询时，JDBC驱动尝试复用已有TLS会话，导致SQL Server无法处理直接关闭连接。
2. 加密数据包分片不匹配：开启加密后，查询返回的结果集数据包较大时，Java 1.8的TLS层分片方式与SQL Server 2008 R2的预期不符，引发通信中断。

连接阶段仅完成TLS握手，未传输实际查询数据，所以能成功建立连接；查询阶段需要传输更大的数据包，才会触发TLS层的兼容性问题，这就是连接成功但查询失败的核心原因。

可行解决方案 #

1. 禁用TLS会话复用
   在JVM启动参数中添加：

   -Djdk.tls.useExtendedMasterSecret=false
   

   该参数关闭Java 1.8默认启用的扩展主密钥机制，避免SQL Server无法处理会话复用请求。

2. 调整JDBC驱动加密参数
   除setEncrypt(true)外，额外配置以下参数：

   dataSource.setTrustServerCertificate(true); // 跳过证书验证（适配SQL Server 2008 R2的旧证书）
   dataSource.setSSLProtocol("TLSv1");
   dataSource.setSendStringParametersAsUnicode(false); // 减少数据传输量，降低分片冲突概率
   

3. 临时降级JDK版本（备选）
   若上述参数无效，可尝试使用Java 1.7，其TLSv1实现更兼容旧版SQL Server加密逻辑，但注意Java 1.7已停止支持，仅作为应急方案。

内容的提问来源于stack exchange，提问作者Thibault Coudert