传输级与消息级安全性
我正在读一本关于 WCF 的书，作者就使用消息级安全性相对于使用传输级安全性的优点进行了辩论。无论如何，我在作者的论点中找不到任何逻辑
交通的一个限制 安全性在于它依赖于每一个 “步骤”和网络参与者 一致配置的路径 安全。换句话说，如果一条消息 必须通过中介 在到达目的地之前，有 没有办法保证运输 该步骤已启用安全性 在中介之后（除非 中介机构完全受控于 原始服务提供商）。如果 安全不忠实 转载，数据可能是 下游受到损害。
消息安全专注于确保消息的完整性和隐私性 单独的消息，不考虑 对于网络。通过机制 例如加密和签名 公钥和私钥，消息 即使通过发送，也会受到保护 无保护的运输（例如普通 HTTP）。
一个）
如果安全性不忠实 转载，数据可能是 下游受到损害。
确实如此，但假设两个系统通信使用 SSL 并因此使用证书，那么它们交换的数据无法由中介解密，而只能更改，接收者会注意到这一点并因此拒绝数据包？！
b) 无论如何，据我理解上述引用，它意味着如果两个系统建立 SSL 连接，并且如果中间系统 S 启用了 SSL 并且如果 S也属于黑客，那么 S （又名黑客）将无法拦截通过它传输的 SSL 流量？但如果S没有启用SSL，那么黑客就能拦截SSL流量吗？这没有道理！
c)
消息安全侧重于确保个人的完整性和隐私性 真实消息，不考虑网络。通过诸如此类的机制 通过公钥和私钥进行加密和签名，该消息将是 即使通过不受保护的传输（例如纯 HTTP）发送，也会受到保护。
这是没有意义的，因为传输级安全性也可以使用加密和证书，那么为什么在消息级使用私钥/公钥比在传输级使用它们更安全呢？也就是说，如果中介能够拦截 SSL 流量，为什么它不能拦截通过消息级私钥/公钥保护的消息？
谢谢
I'm reading a book on WCF and author debates about pros of using message-level security over using transport-level security. Anyways, I can't find any logic in author's arguments
One limitation of transport
security is that it relies on every
“step” and participant in the network
path having consistently configured
security. In other words, if a message
must travel through an intermediary
before reaching its destination, there
is no way to ensure that transport
security has been enabled for the step
after the intermediary (unless that
interme- diary is fully controlled by
the original service provider). If
that security is not faithfully
reproduced, the data may be
compromised downstream.Message security focuses on ensuring the integrity and privacy of
individ- ual messages, without regard
for the network. Through mechanisms
such as encryption and signing via
public and private keys, the message
will be protected even if sent over an
unprotected transport (such as plain
HTTP).
a)
If that security is not faithfully
reproduced, the data may be
compromised downstream.
True, but assuming two systems communicating use SSL and thus certificates, then the data they exchange can't be decrypted by intermediary, but instead it can only be altered, which the receiver will notice and thus reject the packet?!
b) Anyways, as far as I understand the above quote, it is implying that if two systems establish a SSL connection, and if intermediary system S has SSL enabled and if S is also owned by a hacker, then S ( aka hacker ) won't be able to intercept SSL traffic travelling through it? But if S doesn't have SSL enabled, then hacker will be able to intercept SSL traffic? That doesn't make sense!
c)
Message security focuses on ensuring the integrity and privacy of individ-
ual messages, without regard for the network. Through mechanisms such
as encryption and signing via public and private keys, the message will be
protected even if sent over an unprotected transport (such as plain HTTP).
This doesn't make sense, since transport-level security also can use encryption and certificates, so why would using private/public keys at message-level be more secure than using them at transport-level? Namelly, if intermediary is able to intercept SSL traffic, why wouldn't it also be able to intercept messages secured via message-level private/public keys?
thank you
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
考虑 SSL 拦截的情况。
一般来说，如果您与服务器有 SSL 加密连接，则可以相信您“确实*连接到该服务器，并且服务器所有者已向相互信任的第三方（例如 Verisign、Entrust 或 Thawte）明确表明了自己的身份” （通过提供标识其姓名、地址、联系信息、开展业务的能力等的凭据，并接收由第三方签名会签的证书，该证书使用 SSL 向最终用户保证用户之间的通信。浏览器（客户端）和服务器的 SSL 端点（可能不是服务器本身，而是安装了 SSL 证书的某些交换机、路由器或负载平衡器）是安全的，任何拦截该流量的人都会收到官方信息，如果他们篡改了该流量。无论如何，流量都会被服务器拒绝。
但是 SSL 拦截在许多公司中变得很常见。通过 SSL 拦截，您可以“请求”到（例如）www.google.com（公司的交换机）的 HTTPS 连接。路由器/代理为您提供一个有效的证书，将 www.google.com 命名为端点（这样您的浏览器就不会抱怨名称不匹配），而不是由相互信任的第三方进行会签，它由他们自己的证书颁发机构（在公司的某个地方运行）会签，而该颁发机构也恰好受到您的浏览器的信任（因为它位于公司可以控制的受信任的根 CA 列表中）。
然后，该公司的代理会与您的目标站点（在本例中为 www.google.com）建立单独的 SSL 加密连接，但中间的代理/交换机/路由器现在能够记录您的所有流量。
您仍然会在浏览器中看到一个锁定图标，因为到达公司内部 SSL 端点的流量已使用其自己的证书进行加密，并且从该端点到最终目的地的流量已使用目标的 SSL 证书重新加密，但是中间的设备（代理/路由器/交换机）现在可以记录、重定向甚至篡改您的所有流量。
消息级加密将保证消息保持加密状态，即使在流量本身被解密的这些中间“跃点”期间也是如此。
负载平衡是另一个很好的例子，因为 SSL 证书通常安装在代表 SSL 端点的负载平衡器上。然后，负载均衡器负责决定将现已解密的流量发送到哪台物理机进行处理。您的消息在最终到达可以理解和处理消息的服务端点之前可能会经历几个像这样的“跃点”。
Consider the case of SSL interception.
Generally, if you have an SSL encrypted connection to a server, you can trust that you "really are* connected to that server, and that the server's owners have identified themselves unambiguously to a mutually trusted third party, like Verisign, Entrust, or Thawte (by presenting credentials identifying their name, address, contact information, ability to do business, etc., and receiving a certificate countersigned by the third party's signature). Using SSL, this certificate is an assurance to the end user that traffic between the user's browser (client) and the server's SSL endpoint (which may not be the server itself, but some switch, router, or load-balancer where the SSL certificate is installed) is secure. Anyone intercepting that traffic gets gobbledygook and if they tamper with it in any way, then the traffic is rejected by the server.
But SSL interception is becoming common in many companies. With SSL interception, you "ask" for an HTTPS connection to (for example) www.google.com, the company's switch/router/proxy hands you a valid certificate naming www.google.com as the endpoint (so your browser doesn't complain about a name mismatch), but instead of being countersigned by a mutually trusted third party, it is countersigned by their own certificate authority (operating somewhere in the company), which also happens to be trusted by your browser (since it's in your trusted root CA list which the company has control over).
The company's proxy then establishes a separate SSL-encrypted connection to your target site (in this example, www.google.com), but the proxy/switch/router in the middle is now capable of logging all of your traffic.
You still see a lock icon in your browser, since the traffic is encrypted up to your company's inner SSL endpoint using their own certificate, and the traffic is re-encrypted from that endpoint to your final destination using the destination's SSL certificate, but the man in the middle (the proxy/router/switch) can now log, redirect, or even tamper with all of your traffic.
Message-level encryption would guarantee that the message remains encrypted, even during these intermediate "hops" where the traffic itself is decrypted.
Load-balancing is another good example, because the SSL certificate is generally installed on the load balancer, which represents the SSL endpoint. The load balancer is then responsible for deciding which physical machine to send the now-decrypted traffic to for processing. Your messages may go through several "hops" like this before it finally reaches the service endpoint that can understand and process the message.
我想我明白他的意思了。像这样说：
Web客户端--->演示网络服务器--->对数据库的 Web 服务调用
在这种情况下，您依赖于中间服务器在数据到达数据库之前再次加密数据。如果消息被加密，则只有后端知道如何读取它，因此中间并不重要。
I think I see what he's getting at. Say like this:
Web client ---> Presentation web server ---> web service call to database
In this case you're depending on the middle server encrypting the data again before it gets to the database. If the message was encrypted instead, only the back end would know how to read it, so the middle doesn't matter.