Bra*_*ndi 7 ssl encryption connection ssl-certificate sql-server
我需要为我的应用程序和 Sql Server 2008 之间的传输实现 SSL。
我使用的是 Windows 7、Sql Server 2008、Sql Server Management Studio，我的应用程序是用 c# 编写的。
我试图按照 MSDN 页面上的创建证书以及“特定客户端的加密”下的这个页面进行操作，但我感到非常困惑。我需要一些小步骤才能在成功实施加密的道路上走得更远。
首先，我不了解MMC。我在那里看到很多证书......这些证书是我应该用于我自己的加密还是用于已经存在的东西？另一件事，我假设所有这些证书都是位于我本地计算机上的文件，那么为什么会有一个名为“个人”的文件夹？
其次，为了避免上述问题，我做了一个自签名程序集的小实验。如上面的 MSDN 链接所示，我使用在 SSMS 中执行的 SQL 创建了一个自签名证书。然后我使用以下连接字符串进行连接：
Data Source=myServer;Initial Catalog=myDatabase;User ID=myUser;Password=myPassword;Encrypt=True;TrustServerCertificate=True
它连接，工作。然后我删除了我刚刚创建的证书，它仍然有效。显然它从来没有做任何事情，但为什么不呢？我如何判断它是否真的“有效”？我想我可能错过了（以某种方式？）将文件从 SSMS 移到客户端的中间步骤？
我一点也不知道我在做什么，因此非常感谢您能给我的任何帮助、建议、评论和参考。
先感谢您。:)
如果我正确理解 MSDN 规范，那么您只需要在连接字符串中指定即可Encrypt=True;TrustServerCertificate=True。这意味着客户端请求加密并愿意接受服务器可能使用的任何证书。如果没有其他可用的，服务器始终具有在服务器启动时生成的自签名证书以供使用。如果客户端愿意接受任何证书，那么它将接受该服务器的临时自签名证书，与任何证书一样好。
这样的设置提供的是您的应用程序和服务器之间的加密通信通道，该通道不能轻易被窃听。但是，该通道对恶意中间人攻击是开放的。如果攻击者可以欺骗客户端而不是服务器连接到他（例如，通过控制 DNS 记录，更准确地说是客户端将使用的 DNS 服务器 IP，这是一个简单的 DHCP 设置来控制），那么攻击者可以呈现任何证书和客户端将接受它，然后它可以与客户端进行完整的身份验证往返，从而获得使用的 SQL 用户名和密码，然后它可以连接到真正的服务器并来回转发所有通信，使用一个免费查看所有内容。客户永远不会知道正在被“监控”。这就是“中间人”攻击。
为了防止上述情况，客户必须删除了TrustServerCertificate=True从连接字符串。一旦这样做虽然，由服务器使用的证书具有由客户信任，这就是当所有的并发症出现。如果您对加密流量的较弱设置没问题，但您知道自己可能会受到中间人攻击并且您没问题，那么请使用更简单的TrustServerCertificate=True设置。如果没有，那么不幸的是，您必须真正了解自己在做什么，而且并非微不足道。如果数据是这样 重要的是，也许为您的服务器支付 VeriSign、Thawte 或 GlobalSign（这些是每个 Windows 客户端信任的 3 个根）证书（约 500 美元/年）并不是那么古怪。