Condividi tramite


SQL Server 连接加密 (2) -- SQL Server connection encyption

上篇文章中我们讲到了SQL Server在建立连接时的加密。今天我们继续讨论SQL Server在建立完连接后在该连接上的数据传送加密。

默认情况下SQL Server是否加密收发的数据包


答案是否定的。SQL Server默认只在建立连接时进行加密以保护客户端发送过来的账户登录信息

在上篇文章中所做的实验,我们可以看到SSL已经启用,并且在所有网络包中都找不到密码的明文。但是如果你选中任意一个TDS:SQLBatch的数据包,你可以看到类似如下的结果:

 

可以清楚的看到客户端发送的查询语句。如果你查看SQL Server返回来的数据包的话,你也同样能看到查询结果的数据明文。那么怎么来加密客户端和SQL Server之间传输的数据呢?

加密SQL Server收发的数据包


我们可以通过SQL Server的configuration Manager来配置SQL Server使得它加密和客户端之间的数据交换。在Configuration Manager中分别有两个地方来配置。

1. SQL Server服务器端的加密配置。

如上图所示,右键点击“Protocols for MSSQLSERVER”,选择属性,你就可以看到Force Encryption选项。默认状态下这个选项是设置为No的,也就是说SQL Server不进行加密。

当把该选项设置为on之后,SQL Server就会要求对所有它和客户端之间的数据包传送进行加密,无论客户端是否配置为要求加密。此时用来加密的密钥仍旧是之前在建立连接阶段使用的证书。

需要注意的是,如果你是手动配置证书给SQL Server的话,你可能会发现一个现象。即使该证书已经过了有效期,或者该证书的根证书不受客户端的信任,客户端仍旧可以顺利的使用这个证书和SQL Server进行交流。这是一个by desing的行为。如果你要求你的客户端一定要信任该证书才可以连接的话,你就必须要配置客户端的加密选项。

如果你对如何手动配置证书不熟悉的话,可以参考这篇文章

 

2. 客户端的加密配置。

如果SQL Server服务器端的Force Encryption的选项为No的话,那么是否对数据进行加密就完全取决于客户端的配置,也就是客户端的数据库连接驱动的配置。

在Configuration Manager中,可以配置Native Client驱动程序的加密配置,如下图所示。

 

当Force Protocol Encryption为Yes的话,就表明客户端要求加密数据包。此时客户一定要信任SQL Server端的证书,否则连接无法建立。另外,需要注意的是,此处的配置只对使用Native Client的客户端程序有效果。其他驱动程序也会有相应的方法分别作配置。如ODBC驱动就可以通过Cliconfg控制台来配置,等等。

如上面提到的,如果客户端要求加密的话,则客户端一定要信任服务器端的证书。在这种情况下,你手动配置的证书(无论你是从第三方获得的,还是企业内部证书服务器获得的,甚至是使用SelfSSL或者Makecert获得的证书)都是正常工作的。唯一的例外是SQL Server自动生成的证书。每次SQL Server启动时,它自动生成的证书都是不一样的,而且该证书的subject属性的CN域和SQL Server主机的FQDN是不一样的。这种情况下客户端是不信任这张证书的,因为它的CN域和FQDN不符合。