我正在阅读一本关于WCF的书和作者关于使用传输级安全性使用消息级安全性的优点的辩论。无论如何，我在作者的论点中找不到任何逻辑
运输的一个限制 安全性是它依赖于每一个 “步骤”和网络参与者 路径始终如一 安全。换句话说，如果是消息 必须通过中间人旅行 在到达目的地之前，那里 没办法确保运输 已为该步骤启用安全性 中介之后（除非那个 中间人完全由...控制 原始服务提供商）。如果 安全不忠实 转载，数据可能 下游受损。
邮件安全性侧重于确保完整性和隐私性 个人信息，不顾一切 对于网络。通过机制 例如加密和签名通过 公钥和私钥，消息 即使发送过，也会受到保护 无保护的运输（如平原 HTTP）。
a）
如果安全性不忠实 转载，数据可能 下游受损。
是的，但假设两个系统通信使用SSL并因此使用证书，那么他们交换的数据不能被中间人解密，而是只能改变它，接收者会注意到并因此拒绝该数据包？！< / p>
b）无论如何，据我所知，上述引用，暗示如果两个系统建立SSL连接，并且中间系统S启用了SSL并且S也拥有一个黑客，然后S（又名黑客）将无法拦截通过它的SSL流量？但如果S没有启用SSL，那么黑客就能拦截SSL流量？这没有意义！
c）中
消息安全的重点是确保个人的完整性和隐私性 消息，不考虑网络。通过这样的机制 通过公钥和私钥加密和签名，消息将是 即使通过不受保护的传输（例如普通HTTP）发送也受到保护。
这没有意义，因为传输级安全性也可以使用加密和证书，那么为什么在消息级别使用私钥/公钥比在传输级别使用它们更安全？也就是说，如果中介能够拦截SSL流量，为什么它也不能拦截通过消息级私有/公共密钥保护的消息？
谢谢
答案 0 :(得分：8)
考虑SSL拦截的情况。
通常，如果您与服务器建立了SSL加密连接，则可以相信您“确实*已连接到该服务器，并且服务器所有者已明确地向相互信任的第三方发现自己，例如Verisign，Entrust或Thawte（通过提供凭证来识别其姓名，地址，联系信息，开展业务的能力等，并接收由第三方签名会签的证书）。使用SSL，此证书可确保最终用户获得流量在用户的浏览器（客户端）和服务器的SSL端点（可能不是服务器本身，但安装了SSL证书的某些交换机，路由器或负载均衡器）之间是安全的。任何拦截该流量的人都会获得gobbledygook，如果他们以任何方式篡改它，然后服务器拒绝流量。
但SSL拦截在许多公司中变得越来越普遍。通过SSL拦截，您“询问”与（例如）www.google.com的HTTPS连接，公司的交换机/路由器/代理向您发送有效证书，将www.google.com命名为端点（因此您的浏览器不会抱怨名称不匹配），但它不是由相互可信第三方会签，而是由他们自己的证书颁发机构（在公司某处运营）进行会签，这也恰好受到信任您的浏览器（因为它位于公司可以控制的受信任的根CA列表中）。
然后，公司的代理会为您的目标网站（在此示例中为www.google.com）建立单独的SSL加密连接，但中间的代理/交换机/路由器现在能够记录您的所有流量。
您仍然会在浏览器中看到一个锁定图标，因为流量使用自己的证书加密到公司的内部SSL端点，并使用目标的SSL证书将流量从该端点重新加密到最终目的地，但是中间人（代理/路由器/交换机）现在可以记录，重定向甚至篡改您的所有流量。
消息级加密可以保证邮件保持加密状态，即使在流量本身被解密的中间“跳”期间也是如此。
负载平衡是另一个很好的示例，因为SSL证书通常安装在负载均衡器上，负载均衡器代表SSL端点。然后负载均衡器负责决定将现在解密的流量发送到哪个物理机器进行处理。在您的消息最终到达可以理解和处理消息的服务端点之前，您的消息可能会经历几个“跳”。
答案 1 :(得分：6)
我想我看到了他的目标。这样说：
网络客户端---＆gt;演示网络服务器---＆gt; Web服务调用数据库
在这种情况下，您依赖中间服务器在数据到达数据库之前再次加密数据。如果消息是加密的，只有后端会知道如何读取它，所以中间无所谓。