我们正在认证我们的保健产品（Hitech 认证）。认证过程的标准之一是我们的产品在通过网络发送患者信息时应该能够使用“散列”。我们的产品是一个直接连接到 Sql Server 2005 数据库的胖客户端。因此，当我们将患者信息从客户端发送到数据库存储过程时，它应该使用“散列”来确保信息在传输过程中没有被更改。
现在，我们计划使用 SSL 安全连接将我们的客户端连接到 Sql Server。当我阅读 SSL 协议时，似乎 SSL 在内部使用散列。因此，如果那是真的，我可以通过在客户端和 sql svr 之间使用 SSL 连接来自动满足散列要求。
所以这是我的问题
即使 SSL 使用散列，也只能确保 SSL 处理的传输部分。客户端应用程序和网络连接之间以及网络连接和服务器应用程序之间的任一端仍然存在间隙。
您需要创建数据的散列，该散列与数据一起从客户端应用程序内部一直传输到服务器应用程序内部。
这取决于。两个谈判方可以协商保护级别和使用的算法。最常见的情况是协商使用TLS，而不是 SSL，请求消息隐私（即加密）并请求防篡改（即签名）。TLS 使用基于HMAC的每个消息散列，请参阅RFC2246的第 5 章。SSL 使用MAC，它比 HMAC 稍弱（MAC 在其摘要中不包含秘密）。
在 10000 英尺的执行级别视图中，答案是“是的，SSL 对每条消息进行哈希处理”。在合规部署中通常需要对 SQL Server 客户端协议强制执行 SSL 加密。有关更多详细信息和指导，请查看SQL Server 合规性的网络广播和白皮书。
当数据通过 SSL 连接传输时，每条消息是否都在内部附加了一个哈希，以便 SSL 协议验证数据没有被修改？
是的。它将密钥 MAC 附加到每个交换的 TLS 记录。
SSL 是否仅在其握手的初始步骤中使用散列机制？
不，它贯穿始终。
如果 SSL 确实为每条消息附加了一个散列，那么“公钥”是否用于创建散列？
不可以。共享密钥用于创建散列。
有关详细信息，请参阅RFC2246。
SSL 或 TLS（至少现在您可能能够使用 TLSv1.0，即使在谈论“SSL”时也是如此），旨在保护目标“ [...] 在两个通信应用程序之间提供隐私和数据完整性"（参见RFC）。
RFC 4346 继续说：
TLS 记录协议提供具有两个基本属性的连接安全性：
- 连接是私有的。[...]
- 连接可靠。消息传输包括使用密钥 MAC 的消息完整性检查。安全散列函数（例如，SHA、MD5 等）用于 MAC 计算。记录协议可以在没有 MAC 的情况下运行，但通常仅在此模式下使用，而另一个协议正在使用记录协议作为协商安全参数的传输。
所以，是的，它会检测到破坏数据传输的尝试（有意或无意）。
SSL 比散列更强大。它应该满足您的要求。
我会更清楚：
SSL 对传输的所有数据进行加密。这意味着无法读取数据，并且如果更改了数据，则无法解密。因此，SSL 可以防止您窃听 droppers 和更改。
编写该要求时期望大多数通信都是明文进行的。通过使用 SSL，您可以轻松满足这一要求。
重要提示：确保您的 SSL 通信正确实施——这是单点故障。