傳輸級別與消息級別的安全性

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端點的負載平衡器上。然後，負載均衡器負責決定將現在解密的流量發送到哪個物理機器進行處理。在它最終到達可理解和處理消息的服務端點之前，您的消息可能會像這樣經歷幾次「跳躍」。