SQL 服务器 TLS 1.2 通信真的加密了吗？

Question

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

1. 这种通信确实是加密的。 如果不是为什么我在 SQL 服务器中看到不同的状态
2. 我在某处读到 TCP 是二进制协议。 如果是这样，即使此通信未加密，为什么我看到的是纯文本？

Answer 1

这不是 TDS 问题（SQL Server 使用的协议）。 当您使用像 Fiddler 这样的调试代理并信任代理的证书，或将其配置为使用受信任的证书时，浏览器也会发生同样的事情。 最有可能的是，您在设置期间或通过其设置信任了 EchoMirage 的证书并忘记了它。

SSL/TLS 通过证书验证对方来防止中间人攻击。 加密是不够的。 如果没有验证，客户端和服务器之间的代理可能会冒充另一方，与每一方建立加密通信，解密它收到的数据包，检查它们，然后使用另一方的密钥再次加密它们并将它们一起发送。 如果没有验证，客户端和服务器都不会知道有人拦截了连接。

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

Fiddler、WireShark 和其他类似工具通过充当代理并使用其证书在任何一方建立通信来解密流量。 尽管启用了证书验证，浏览器（或 SQL Server 客户端）将拒绝连接。 如果您在使用 Fiddler 时尝试通过 HTTPS 连接到网站，您会看到一个红色警告页面，指出连接不安全。

为了允许这样的连接，有人必须去并明确信任该工具的证书。 所有工具都可以通过其设置执行此操作，但所有操作系统在将证书添加到受信任列表之前都需要权限提升和用户确认。

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

文档中的在 SQL Server Native Client中使用加密而不进行验证的页面解释了当您不使用验证时会发生什么，并对它发出警告。

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

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

Answer 2

这是一个 TDS 问题（SQL 服务器使用的协议），绝不是由 WireShark 引起的。

TLS 加密仅在登录过程中使用，以确保凭证不会在未加密的情况下通过网络传递。

之后，剩余的批量传输查询和结果集不会在线上加密。

为了启用数据加密（而不仅仅是登录过程），您需要在连接字符串中Use Encryption for Data连接字符串关键字：

Use Encryption for Data=true

• Use Encryption for Data
• SSPROP_INIT_ENCRYPT
• “指定数据在通过网络发送之前是否应该加密。可能的值为“真”和“假”。默认值为“假”。”

请注意：如果您enable encryption for data ，而服务器没有有效证书（即默认证书），那么您在连接时会收到错误消息。 客户端将检测到服务器提供了无效的证书，并停止连接。 为了使您的系统可靠，您需要在连接字符串中包含Trust Server Certificate=true ：

Use Encryption for Data=true;Trust Server Certificate=true

更好的替代方法是在服务器上打开强制数据加密的选项，并且不要在连接字符串中指定Use Encryption for Data或Trust Server Certificate 。

当是服务端要求加密时，客户端不会关心服务端出示的证书（MSOLEDBSQL19除外，默认是坏的，即使是服务端也需要指定Trust Server Certificate=true首先想要加密。