传输级别与消息级别的安全性

Question

我正在阅读WCF的一本书，并就使用传输级别安全性的使用消息级别安全性的专家进行了辩论。不管怎么说，我不能在笔者的论点找到任何逻辑运输

一个限制 安全是，它依赖于具有持续CON组fi gured 安全网络 路径上的每个 “一步”和参与者。换句话说，如果消息 必须在到达目的地之前通过中介 旅行，有 没有办法保证运输安全 已为中介（后步骤 启用，除非是 中介是完全控制由原来的服务提供商 ）。如果 表示安全性不严格 转载，则数据可能是 下游受损。

信息安全重点是确保完整性和 individ- UAL消息的保密性，不考虑 的网络。通过机制 （如加密和通过 公钥和私钥签名），即使通过 未受保护的传输（例如普通的 HTTP）发送，邮件 也将受到保护。

一个）

如果安全不是忠实 再现时，数据可以被 下游损害。

真，但假设这两个系统进行通信使用SSL和由此证书，则它们交换数据不能被解密的中介，而是它只能被改变，其中接收器会注意到并因此拒绝数据包？！

B）反正，据我了解以上报价，则暗示，如果两个系统建立SSL连接时，如果中介系统S已启用SSL如果S也被黑客所拥有，那么S（又名黑客）将无法拦截穿越它的SSL流量？但是如果S没有启用SSL，那么黑客将能够拦截SSL流量？这没有道理！

C）

消息安全重点是确保完整性和individ- UAL消息的私密性，而无需在网络方面。通过 等机制作为通过公钥和私钥进行加密和签名的机制，即使通过未受保护的传输（例如普通HTTP）发送，该邮件也会受到 保护。

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

谢谢

Answer 1

我想我明白他在做什么。这样说：

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

在你依赖中间服务器再次加密数据在它到达之前，这种情况下数据库。如果邮件被加密，只有后端才会知道如何阅读，所以中间没关系。

Answer 2

考虑SSL拦截的情况。一般来说，如果你有一个到服务器的SSL加密连接，你可以相信你真的“连接到了那个服务器上，并且服务器的所有者已经明确地向一个相互信任的第三方确认了自己，比如Verisign， Entrust或Thawte（通过提供标识其名称，地址，联系信息，开展业务的能力等等，以及接收由第三方签名签名的证书）。使用SSL，此证书是对最终用户的保证：用户的浏览器（客户端）和服务器的SSL端点（可能不是服务器本身，但安装了SSL证书的一些交换机，路由器或负载均衡器）之间的流量是安全的。拦截该流量的任何人都会获得gobbledygook，如果他们以任何方式篡改它，然后流量被服务器拒绝。

但是SSL拦截在许多公司中越来越普遍。通过SSL拦截，您“请求”与（例如）www.google.com的HTTPS连接，该公司的交换机/路由器/代理服务器会为您提供一个名为www.google.com的有效证书作为终端（因此您的浏览器不会“ t抱怨名称不匹配），但它不会被可信的第三方签字，而是由他们自己的证书颁发机构（在公司的某个地方操作）进行签名，这也正好是您的浏览器所信任的（因为它是在您公司控制的可信根CA列表中）。

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

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

即使在流量本身被解密的这些中间“跳跃”期间，消息级加密也能保证消息保持加密。

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