SSL 在内部使用散列吗?

发布于 2024-10-01 00:15:57 字数 480 浏览 5 评论 0原文

我们正在认证我们的保健产品(高科技认证)。认证过程的标准之一是我们的产品在通过网络发送患者信息时应能够使用“散列”。我们的产品是一个胖客户端,直接连接到Sql Server 2005数据库。因此,当我们将患者信息从客户端发送到数据库存储过程时,它应该使用“散列”来确保信息在传输过程中不会被更改。

现在,我们计划使用 SSL 安全连接将客户端连接到 Sql Server。当我读到 SSL 协议时,似乎 SSL 在内部使用了哈希。因此,如果这是真的,我可以通过在客户端和 sql svr 之间使用 SSL 连接来自动满足哈希要求。

所以这是我的问题

  • 当数据通过 SSL 连接传输时,每条消息是否在内部附加一个哈希值,以便 SSL 协议验证数据未被修改?
  • SSL 是否仅在握手的初始步骤中使用散列机制?那么握手完成后,它只是加密/解密数据,而不涉及任何哈希机制?
  • 如果 SSL 确实为每条消息附加哈希值,那么“公钥”是否用于创建哈希值?

We are in the process of certifying our health care product (Hitech certification). One of the criteria of the certification process is that our product should be capable of using "hashing" when sending patient information over the network. Our product is a thick client that connects directly to Sql Server 2005 database. So when we send patient information from client to DB store procedure, it should use "hashing" to make sure that the information wasn't altered in transit.

Now, we are planning to connect our client to the Sql Server using SSL secure connection. When I read about SSL protocol, it seems like SSL uses hashing internally. So if thats true, I could automatically satisfy the hashing requirement by using SSL connection between client and sql svr.

So here are my Questions

  • When data is transmitted over an SSL connection, is each message attached with a hash internally, such that the SSL protocol verifies that data hasnt been modified?
  • Does SSL use the hashing mechanism only during the initial steps of its handshake? So after the handshake is complete, it only encrypts/decrypts data without any hashing mechanism involved?
  • If SSL does attach a hash for each message, is the "public key" used to create the hash?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

浸婚纱 2024-10-08 00:15:57

即使 SSL 使用散列,也只能确保 SSL 处理的传输部分。客户端应用程序和网络连接之间以及网络连接和服务器应用程序之间的任一端仍然存在间隙。

您需要创建数据的哈希值,该哈希值随数据一起从客户端应用程序内部传输到服务器应用程序内部。

Even if SSL uses hashing, that will only ensure the part of the transmission that SSL handles. There is still a gap at either end between the client application and the network connection, and between the network connection and the server application.

You need to create a hash of the data that travels with the data all the way from inside the client application to inside the server application.

野心澎湃 2024-10-08 00:15:57

这取决于。谈判双方可以协商保护级别和使用的算法。最常见的情况是协商使用TLS,而不是SSL,请求消息隐私(即. 加密)和篡改保护被请求(即签名)。 TLS 使用基于 HMAC 的每条消息哈希,请参阅 RFC2246。 SSL 使用 MAC,它比 HMAC 稍弱(MAC 不包含密钥)在其摘要中)。

从 10000 英尺的执行层来看,答案是“是的,SSL 对每条消息进行哈希处理”。在合规部署中通常需要对 SQL Server 客户端协议实施 SSL 加密。有关更多详细信息和指导,请查看网络广播和白皮书,网址为 SQL Server 合规性< /a>.

It depends. The two negotiating parties can negotiate the level of protection and the algorithms used. The most common case is that the negotiation uses TLS, not SSL, message privacy is requested (ie. encryption) and tampering protection is requested (ie. signing). TLS uses per message hashing based on HMAC, see chapter 5 of RFC2246. SSL uses a MAC, which is slightly weaker than an HMAC (an MAC does not contain a secret in its digest).

At a 10000 ft executive level view the answer is 'Yes, SSL hashes each message'. Enforcing SSL encryption on the SQL Server client protocol is usualy required in compliant deployments. For more details and guidance check the webcast and white papers at SQL Server Compliance.

轮廓§ 2024-10-08 00:15:57

当数据通过 SSL 连接传输时,每条消息是否都会在内部附加一个哈希值,以便 SSL 协议验证数据未被修改?

是的。它将一个密钥 MAC 附加到每个交换的 TLS 记录中。

SSL 是否仅在握手的初始步骤中使用哈希机制?

不,它贯穿始终。

如果 SSL 确实为每条消息附加哈希值,那么“公钥”是否用于创建哈希值?

不会。共享秘密用于创建哈希。

有关详细信息,请参阅 RFC2246

When data is transmitted over an SSL connection, is each message attached with a hash internally, such that the SSL protocol verifies that data hasnt been modified?

Yes. It appends a keyed MAC to each TLS record exchanged.

Does SSL use the hashing mechanism only during the initial steps of its handshake?

No, it occurs throughout.

If SSL does attach a hash for each message, is the "public key" used to create the hash?

No. A shared secret is used to create the hash.

See RFC2246 for details.

絕版丫頭 2024-10-08 00:15:57

SSL 比哈希更强大。它应该满足你的要求。

我会说得更清楚:

SSL 会对传输的所有数据进行加密。这意味着数据无法读取,并且如果更改也无法解密。因此,SSL 可以防止您被窃听和更改。

该要求的编写期望大多数通信都是以明文方式进行的。通过使用 SSL,您可以轻松满足此要求。

重要提示:确保正确实施 SSL 通信——这是单点故障。

SSL is stronger than hashing. It should satisfy your requirement.

I will be clearer:

SSL encrypts all data that is transmitted. This means that the data can not be read and if it is changed it can not be decrypted. SSL thus prevents you from eaves droppers and from changes.

The requirement was written with an expectation that most communication was done in the clear. With the use of SSL you easily satisfy this requirement.

Important Note: Make sure you SSL communication is correctly implemented -- it is the single point of failure.

混浊又暗下来 2024-10-08 00:15:57

SSL 或 TLS(至少现在您可能能够使用 TLSv1.0,即使在谈论“SSL”时也是如此),旨在保护“[...] 之间提供隐私和数据完整性”两个通信应用程序”(请参阅​​ RFC)。

RFC 4346 继续说道:

TLS 记录协议提供
连接安全有两个基本的
属性:

  • 该连接是私有的。 [...]
  • 连接可靠。消息传输包括消息完整性
    使用密钥 MAC 检查。安全哈希
    函数(例如 SHA、MD5 等)是
    用于MAC计算。记录
    协议可以在没有MAC的情况下运行,
    但一般只用在这个
    当另一个协议正在使用时的模式
    记录协议作为传输
    协商安全参数。

所以,是的,它会检测破坏数据传输的尝试(有意或无意)。

SSL, or TLS (you're likely to be able to use TLSv1.0 at least nowadays, even when talking about "SSL"), aims to protect aims "[...] to provide privacy and data integrity between two communicating applications" (see RFC).

RFC 4346 goes on saying:

The TLS Record Protocol provides
connection security that has two basic
properties:

  • The connection is private. [...]
  • The connection is reliable. Message transport includes a message integrity
    check using a keyed MAC. Secure hash
    functions (e.g., SHA, MD5, etc.) are
    used for MAC computations. The Record
    Protocol can operate without a MAC,
    but is generally only used in this
    mode while another protocol is using
    the Record Protocol as a transport for
    negotiating security parameters.

So, yes, it will detect attempts to corrupt the data transmission (intentional or accidental).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文