SQL Server TLS 1.2 通信真的加密了吗?

Posted

技术标签:

【中文标题】SQL Server TLS 1.2 通信真的加密了吗?【英文标题】:SQL Server TLS 1.2 communication really encrypted? 【发布时间】:2021-10-05 18:45:36 【问题描述】:

我正在编写一个与 SQL Server 连接的 VB6 应用程序。为了保护与数据库的连接,我使用 MSOLEDBSQL 作为支持 TLS 1.2 的提供程序。我还在我的机器上启用了 TLS 1.2。我使用 sys.validation 验证了连接状态。 dm_exec_connections 和 SQL server 显示所有的连接都是加密的。为了双重确认,我尝试使用 echomirage 检查流量,结果令人惊讶。数据未加密,我可以读取所有数据流,如下图所示。我的问题是

    此通信确实是加密的。如果不是,为什么我在 SQL Server 中看到不同的状态 我在某处读到 TCP 是二进制协议。如果是这样,为什么即使此通信未加密,我也会看到纯文本?

【问题讨论】:

你的连接字符串是什么样的?是否包含TrustServerCertificate=true;Encrypt=true; 您确定 EchoMirage 没有显示非 HTTPS 版本的流量吗?这些网络协议应用可以通过充当代理或使用用于加密的本地证书密钥来解密安全流量。 您确定您正在查看正确的捕获吗? SQL Server 的协议不使用 XML。也许您试图发布一个 XML 字符串,或者数据库返回一个 XML 结果,但协议 TDS 不是基于 XML 的。 I read somewhere that TCP is binary protocol. 这不是read somewhere。所有网络协议都是二进制的。所有传输字节。其中一些代表文本,一些不代表。 如果你真的想检查任何东西,请使用 SSMS,而不是旧石器时代的 VB6。与 SQL Server 的实际问题相比,您在代码或使用 ADO 的方式中看到问题的可能性要大得多。 PS:截图其实给你看的是内容是二进制的,右边是翻译成文本的 @Jay 要防止 SQL Server 的 MITM 攻击,您应该使用TrustServerCertificate=true;。这将禁用验证。如果您想使用自签名证书进行测试,您必须将其添加到机器的受信任证书中,not 禁用验证。 Using Encryption Without Validation in SQL Server Native Client 解释。当你不使用验证时会发生什么,并带有一个大的红色警告 【参考方案1】:

这不是 TDS 问题(SQL Server 使用的协议)。当您使用 Fiddler 之类的调试代理并信任该代理的证书或将其配置为使用受信任的证书时,您的浏览器也会发生同样的情况。很可能,您在设置期间或通过其设置信任 EchoMirage 的证书而忘记了它。

SSL/TLS 通过证书验证另一方来防止Man-In-The-Middle 攻击。加密是不够的。在没有验证的情况下,客户端和服务器之间的代理可以伪装成另一方,与每一方建立加密通信,解密它接收到的数据包,检查它们,然后使用另一方的密钥再次加密它们并发送它们。如果没有验证,客户端和服务器都不会知道有人拦截了连接。

使用 SSL/TLS,只有在双方信任彼此的证书时才建立连接。双方通过检查证书是否被明确信任或是否由应用程序信任的证书颁发机构颁发来验证证书。如果验证失败,连接也会失败。

Fiddler、WireShark 和其他类似工具通过充当代理并使用证书在任一端建立通信来解密流量。但是,启用证书验证后,浏览器(或 SQL Server 客户端)将拒绝连接。如果您在使用 Fiddler 时尝试通过 HTTPS 连接到网站,您会收到一个红色警告页面,提示您连接不安全。

要允许此类连接,必须有人去明确信任该工具的证书。所有工具都可以通过它们的设置来做到这一点,但所有操作系统都需要在将证书添加到其受信任列表之前进行权限提升和用户确认。

默认情况下,驱动程序和网络库执行验证。要允许 WireShark 拦截 SQL Server 连接,您必须明确禁用 TrustServerCertificate=true; 验证,或者信任该工具的证书,这可能是您已经做过但忘记的事情。

文档中的页面Using Encryption Without Validation in SQL Server Native Client 解释了当您不使用验证时会发生什么,并发出警告。

如果您使用Encrypt=true 并将TrustServerCertificate 保留为默认值,false、WireShark 或 EchoMirage 将无法拦截,更不用说解密流量了。在这种情况下:

只有在存在可验证的服务器证书时才会进行加密,否则连接尝试会失败。

【讨论】:

Wireshark 不会像代理一样解密,Wireshark 会通过向其提供 TLS 会话的密钥来解密。最常见的方法是通过将环境变量 SSLKEYLOGFILE 设置为文件的 shell 启动您最喜欢的浏览器。然后,浏览器(和其他兼容的 TLS 客户端)将转储主密钥、随机数以及解密 TLS 会话所需的任何其他内容。您可以告诉 Wireshark 查看此文件以尝试 TLS 解密。如果你还没有这样做并且在wireshark中看到纯文本,那么连接没有使用TLS。

以上是关于SQL Server TLS 1.2 通信真的加密了吗?的主要内容,如果未能解决你的问题,请参考以下文章

SQL Server 2008, 2008 R2, 2012 and 2014 完全支持TLS1.2加密传输

为SQL Server配置连接加密

SQL Server 2012 与新 TLS 1.2 标准的兼容性

[转帖]windows 2008 Server R2 /Win7启用TLS 1.2

[技术干货] Zabbix 实现Server和windows的Agent通信加密

java:驱动程序无法通过使用安全套接字层(SSL)加密与 SQL Server 建立安全连接:“The server selected protocol version TLS10 is not a