传输级与消息级安全

Question

我正在阅读一本关于 WCF 的书，作者就使用消息级安全性优于使用传输级安全性的优点进行了辩论。无论如何，我在作者的论点中找不到任何逻辑

运输的一个限制 安全是它依赖于每一个 “步骤”和网络参与者 路径一直配置 安全。换句话说，如果一条消息 必须通过中间人旅行 在到达目的地之前， 是没有办法保证运输 已为该步骤启用安全性 中介后（除非 中介完全由 原始服务提供商）。如果 安全不是忠实的 转载，数据可能是 下游受损。

消息安全侧重于确保消息的完整性和隐私性 个人信息，不考虑 为网络。通过机制 例如加密和签名通过 公钥和私钥，消息 即使通过 未受保护的运输（例如普通 HTTP)。

一）

如果安全性不忠实 转载，数据可能是 下游受损。

是的，但是假设两个通信系统使用 SSL 并因此使用证书，那么它们交换的数据不能被中介解密，而是只能被更改，接收方会注意到并因此拒绝数据包？！

b) 无论如何，据我了解以上引用，这暗示如果两个系统建立 SSL 连接，并且如果中间系统 S 启用了 SSL，并且如果 S 也被黑客拥有，那么S（又名黑客）将无法拦截通过它的 SSL 流量？但是如果S没有启用SSL，那么黑客就可以拦截SSL流量吗？这没有意义！

c)

消息安全侧重于确保个人信息的完整性和隐私性 ual 消息，不考虑网络。通过这样的机制 作为通过公钥和私钥加密和签名，消息将是 即使通过不受保护的传输（例如纯 HTTP）发送也受到保护。

这没有意义，因为传输级别的安全性也可以使用加密和证书，那么为什么在消息级别使用私钥/公钥比在传输级别使用它们更安全？也就是说，如果中介能够拦截 SSL 流量，为什么它也不能拦截通过消息级私钥/公钥保护的消息？

谢谢

Answer 1

考虑 SSL 拦截的情况。

一般来说，如果您与服务器建立了 SSL 加密连接，您可以相信您“确实*连接到该服务器，并且服务器的所有者已向相互信任的第三方（例如 Verisign、Entrust）明确表明自己的身份, 或 Thawte（通过出示标识其姓名、地址、联系信息、开展业务的能力等的凭据，并接收由第三方签名副签的证书）。使用 SSL，此证书向最终用户保证流量在用户的浏览器（客户端）和服务器的 SSL 端点（可能不是服务器本身，而是安装了 SSL 证书的某些交换机、路由器或负载平衡器）之间是安全的。任何拦截该流量的人都会得到 gobbledygook，如果他们以任何方式篡改它，然后流量被服务器拒绝。

但 SSL 拦截在许多公司中变得越来越普遍。通过 SSL 拦截，您“请求”与（例如）www.google.com 建立 HTTPS 连接，公司的交换机/路由器/代理会为您提供一个有效的证书，将 www.google.com 命名为端点（因此您的浏览器不会t 抱怨名称不匹配），但不是由 相互 信任的第三方会签，而是由他们自己的证书颁发机构（在公司的某个地方运营）会签，这也恰好是由您的浏览器（因为它位于公司可以控制的受信任的根 CA 列表中）。

该公司的代理随后会与您的目标网站（在本例中为 www.google.com）建立单独的 SSL 加密连接，但中间的代理/交换机/路由器现在能够记录您的所有流量。

您仍会在浏览器中看到一个锁定图标，因为流量已使用您公司的内部 SSL 证书加密到您公司的内部 SSL 端点，并使用目的地的 SSL 证书从该端点重新加密流量到您的最终目的地，但是中间人（代理/路由器/交换机）现在可以记录、重定向甚至篡改您的所有流量。

消息级加密将保证消息保持加密状态，即使在流量本身被解密的这些中间“跃点”期间也是如此。

负载平衡是另一个很好的例子，因为 SSL 证书通常安装在负载平衡器上，它代表 SSL 端点。然后负载均衡器负责决定将现在解密的流量发送到哪台物理机器进行处理。在最终到达可以理解和处理消息的服务端点之前，您的消息可能会像这样经过几次“跃点”。

Answer 2

我想我明白他的意思了。像这样说：

Web 客户端 ---> 演示 Web 服务器 ---> 对数据库的 Web 服务调用

在这种情况下，您需要依靠中间服务器在数据到达数据库之前再次对其进行加密。如果消息被加密，只有后端知道如何读取它，所以中间没有关系。