选择“加密连接”的意义从 SSMS 连接到 SQL Azure 时从连接属性
我预先感谢您分享您的知识。这是我的问题： 默认情况下，SQL Azure 连接是加密的。那么从 SSMS 连接到 SQL Azure 时，选中连接属性中的“加密连接”复选框有什么意义呢？有什么区别吗？
I thank you in advance for sharing your knowledge. Here is my question:
By default, SQL Azure connections are encrypted. so what is the significance of checking the 'encrypt connection' checkbox in the connection properties while connecting to SQL Azure from SSMS? Does it make any difference?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Paras，
当客户端库首次尝试连接到 SQL Server / SQL Azure 时，它会发送初始连接请求。将此视为“预预连接”请求。此时，客户端不知道是否需要 SSL/加密，并等待 SQL Server/SQL Azure 的答复以确定整个会话（不仅仅是登录序列，整个连接会话）是否确实需要 SSL。响应上设置了一个位来指示这一点。然后客户端库断开连接并使用此信息重新连接。
考虑在客户端和 SQL Azure（或 SQL Server）之间设置一个代理。客户端与代理通信，代理与 SQL Azure/Sql Server 通信。如果您不在客户端上强制加密位，则将其留给代理来加密或不加密会话。代理可以在后端加密连接（对于 SQL Azure 必须如此），但不能在连接的客户端加密，因此可以访问所有敏感数据。因此，检查加密框会绕过“预预连接”请求，该请求可防止任何代理关闭代理客户端上有问题的加密位，从而避免中间人攻击。
希望这是有道理的...:) 如果您下载 Wireshark 并观察预登录数据包会发生什么，您就会明白我的意思。选中该框会更改登录前握手机制，以避免我描述的中间人攻击。
Paras,
When the client library first attempts a connection to SQL Server / SQL Azure, it sends an initial connection request. Consider this a "pre-pre-connection" request. At this point the client does not know if SSL/Encryption is required and waits an answer from SQL Server/SQL Azure to determine if SSL is indeed required throughout the session (not just the login sequence, the entire connection session). A bit is set on the response indicating so. Then the client library disconnects and reconnects armed with this information.
Consider a proxy sitting between the client and SQL Azure (or SQL Server). The client talks to the proxy, and the proxy talks to SQL Azure/Sql Server. If you do not force the encryption bit on the client, you leave it to the proxy to encrypt or not the session. The proxy could encrypt the connection on the backend (it would have to for SQL Azure) but not on the client-side of the connection, hence accessing all your sensitive data. So checking the encryption box bypasses the "pre-pre-connection" request which prevents any proxy from turning off the encryption bit in question on the client side of the proxy, hence avoiding the man-in-the-middle attack.
Hopefully that makes sense... :) If you download Wireshark and watch what happens with the pre-pre-login packets, you will see what I mean. Checking the box changes the pre-login handshake mechanism to avoid the man-in-the-middle attack I described.