我已經閱讀了有關此問題的大量文檔，但仍然無法將所有內容整理在一起，因此我想提出幾個問題。首先，我將以我理解的方式簡要描述身份驗證過程，因為在這方面我可能會誤會：客戶端啟動連接，服務器使用公鑰，一些元數(shù)據和數(shù)字簽名的組合來響應服務器的連接。受信任的權威。然后，客戶端將決定是否信任服務器，并使用公共密鑰對某些隨機會話密鑰進行加密并將其發(fā)回。只能使用存儲在服務器上的私鑰來解密此會話密鑰。服務器執(zhí)行此操作，然后HTTPS會話開始。因此，如果我在上面是正確的，那么問題是在這種情況下中間人攻擊如何發(fā)生？我的意思是，即使有人用公共密鑰攔截了服務器（例如www.server.com）的響應，并且有某種手段使我認為他是www.server.com，他仍然無法解密我的會話密鑰沒有私鑰。說到相互認證，這是否完全關系到服務器對客戶端身份的信心？我的意思是，客戶端已經可以確定自己正在與正確的服務器通信，但是現(xiàn)在服務器希望找出誰是客戶端，對嗎？最后一個問題是關于相互身份驗證的替代方法。如果我在上述情況下充當客戶端，如果在建立SSL會話后在HTTP標頭中發(fā)送登錄名/密碼怎么辦？如我所見，該信息無法被截取，因為連接已被保護，服務器可以依靠它來識別我。我錯了嗎？與相互身份驗證相比，這種方法的缺點是什么（僅安全問題很重要，而實現(xiàn)的復雜性卻不重要）？
3 回答
森欄
TA貢獻1810條經驗 獲得超5個贊
客戶端和服務器之間的任何人都可以在https的中間攻擊中派人。如果您認為這種情況不太可能發(fā)生或罕見，請考慮使用一些商業(yè)產品來系統(tǒng)地解密，掃描和重新加密跨Internet網關的所有 SSL流量。他們通過向客戶端發(fā)送即時創(chuàng)建的ssl證書進行工作，該證書包含從“真實” ssl證書復制而來的詳細信息，但使用其他證書鏈進行了簽名。如果此鏈以瀏覽器的任何受信任CA終止，則該MITM對用戶不可見。這些產品主要出售給公司以“保護”（警察）公司網絡，并且應在用戶的知識和同意下使用。從技術上講，沒有什么可以阻止ISP或任何其他網絡運營商對其的使用。（可以安全地假設NSA 至少具有一個受信任的根CA簽名密鑰）。
如果要提供頁面，則可以包含HTTP標頭，以指示應使用該頁面簽名的公共密鑰。這可能有助于向MITM用戶提醒其“安全”連接，但這是一種首次使用信任技術。如果Bob尚未記錄“真實的”公共密鑰圖釘，那么Mallory只會重寫文檔中的pkp標頭。使用此技術（HPKP）的網站列表非常簡短。它包括谷歌和投遞箱，以他們的功勞。通常，https攔截網關會在使用HPKP的少數(shù)幾個大型受信任站點中瀏覽頁面。如果您不希望看到HPKP錯誤，請當心。
關于密碼，https連接上的所有內容均由https保護，但域名（明文除外）必須是明文，以便可以路由請求。通常，建議不要將密碼放在查詢字符串中，因為它們可能會在日志，書簽等中徘徊。但是，除非https被破壞，否則查詢字符串是不可見的。
慕婉清6462132
TA貢獻1804條經驗 獲得超2個贊
實際上，只有打破了SSL的前提之一，才可能對SSL進行中間人攻擊。
服務器密鑰被竊取-意味著攻擊者可以出現(xiàn)在服務器，有沒有辦法為客戶就知道了。
客戶端信任一個不可信的CA（或已經被盜用其根密鑰的CA）-持有可信CA密鑰的任何人都可以生成一個偽裝成服務器的證書，并且客戶端將信任它。隨著當今瀏覽器中已經存在大量的CA，這可能是一個真正的問題。這意味著服務器證書似乎將更改為另一有效證書，這是大多數(shù)客戶端都對您隱藏的東西。
客戶端不必費心根據其受信任的CA列表正確地驗證證書-任何人都可以創(chuàng)建CA。未經驗證，“ Ben的汽車和證書”將與Verisign一樣有效。
客戶端已受到攻擊，偽造的CA已注入其受信任的根權威中-允許攻擊者生成他喜歡的任何證書，客戶端將信任它。惡意軟件通常會這樣做，例如將您重定向到偽造的銀行站點。
特別是＃2相當令人討厭，即使您為高度信任的證書付費，您的網站也不會以任何方式鎖定該證書，您必須信任客戶端瀏覽器中的所有 CA，因為它們中的任何一個都可能會為您生成偽造的證書您的網站同樣有效。它還不需要訪問服務器或客戶端。
添加回答
舉報
0/150
提交
取消