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

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

传输安全性的一个限制是它依赖于网络路径中的每个"步骤"和参与者具有始终如一的安全性.换句话说,如果消息必须在到达其目的地之前通过中间人传播,则无法确保在中间人之后为该步骤启用传输安全性(除非该中间人完全由原始服务提供商控制) .如果不忠实地再现该安全性,则数据可能在下游受到损害.

消息安全侧重于确保单个消息的完整性和隐私性,而不考虑网络.通过加密和通过公钥和私钥签名等机制,即使通过不受保护的传输(例如普通HTTP)发送,该消息也将受到保护.

一个)

如果不忠实地再现该安全性,则数据可能在下游受到损害.

是的,但是假设两个系统通信使用SSL并因此使用证书,那么他们交换的数据不能被中间人解密,而是只能改变它,接收者会注意到并因此拒绝数据包？!

b)无论如何,据我所知,上述引用,暗示如果两个系统建立SSL连接,并且如果中间系统S启用了SSL并且如果S也是黑客拥有,那么S(也就是黑客)将不会能够拦截通过它的SSL流量吗？但如果S没有启用SSL,那么黑客将能够拦截SSL流量？这没有意义!

C)

消息安全侧重于确保单个消息的完整性和隐私性,而不考虑网络.通过加密和通过公钥和私钥签名等机制,即使通过不受保护的传输(例如普通HTTP)发送,该消息也将受到保护.

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

谢谢

考虑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端点.然后负载均衡器负责决定将现在解密的流量发送到哪个物理机器进行处理.在最终到达可以理解和处理消息的服务端点之前,您的消息可能会经历几个"跳".

我想我看到了他的目标.这样说:

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

在这种情况下,您依赖于中间服务器在数据到达数据库之前再次加密数据.如果消息是加密的,只有后端知道如何读取它,所以中间无所谓.