SSL和中間人誤解

Question

我已經閱讀了大量與此問題相關的文檔，但是我仍然無法將所有代碼拼湊在一起，所以我想問幾個問題。

1. 都按照我的理解，我會簡要說明了認證過程，因爲我可能會在這方面搞錯首先：客戶端啓動一個連接，其中一臺服務器與公共密鑰的組合響應，可信機構的一些元數據和數字簽名。然後，如果客戶信任服務器，則客戶端會做出決定，使用公鑰對一些隨機會話密鑰進行加密並將其發回。該會話密鑰只能使用存儲在服務器上的私鑰解密。服務器執行此操作，然後HTTPS會話開始。

2. 因此，如果我在上面是正確的，那麼問題在於如何在這種情況下發生中間人攻擊？我的意思是，即使有人用公鑰截獲服務器（例如www.server.com）響應，並且有一些手段讓我認爲他是www.server.com，但他仍然無法解密我的會話密鑰沒有私鑰。

3. 說到相互身份驗證，關於服務器對客戶端身份的信心是否全部？我的意思是，客戶端可以確定她正在與正確的服務器進行通信，但現在服務器想要知道客戶是誰，對嗎？

4. 最後一個問題是關於相互認證的替代方案。如果我在所描述的情況下充當客戶端，那麼在SSL會話建立之後，如果我在HTTP頭中發送登錄名/密碼，該怎麼辦？正如我所看到的，這些信息不能被攔截，因爲連接已經安全並且服務器可以依靠它來進行識別。我錯了嗎？與相互認證相比，這種方法有什麼缺點（只有安全問題很重要，而不是實施複雜性）？

Answer 1

對SSL的中間人攻擊實際上只有在SSL的前提條件中的一個被破壞時纔有可能，下面是一些示例;

• 服務器密鑰被竊取 - 意味着攻擊者可以出現在服務器，並沒有沒有爲客戶端知道的方式。

• 客戶端信任一個不可信的CA（或者有一個它的根密鑰被盜） - 擁有一個可信的CA密鑰的用戶可以生成一個僞裝成服務器的證書並且客戶端會信任它。由於今天瀏覽器中已經存在CA的數量，這可能是一個真正的問題。這意味着服務器證書似乎會更改爲另一個有效的證書，這是大多數客戶對您隱藏的內容。

• 客戶端並不打算根據其可信CA的列表正確驗證證書 - 任何人都可以創建一個CA.沒有驗證，「本車和證書」看起來與Verisign一樣有效。

• 客戶端受到攻擊，並且一個僞造的CA已經注入他的信任根權限 - 允許攻擊者生成任何他喜歡的證書，並且客戶端會信任它。惡意軟件往往會這樣做，例如將您重定向到假銀行網站。

尤其＃2是相當惡劣的，即使你付出了一個高度受信任的證書，您的網站將不會在鎖定該證書的任何方式，你必須相信在客戶端的瀏覽器所有 CA的自他們中的任何一個都可以爲您的網站生成一個同樣有效的假證書。它也不需要訪問服務器或客戶端。

Answer 2

除了關於會話密鑰的部分，你所說的一切都是正確的。 CA的重點在於打敗中間人攻擊 - 其他任何事情都是由SSL自己完成的。客戶端身份驗證是用戶名和密碼方案的替代方案。

Answer 3

1. 正確
2. 並非如此正確。在那種攻擊中，中間服務器會收到您的請求，並代表您將其發送到目的地。然後對結果做出迴應。實際上，它是中間人服務器，它與您建立安全連接，而不是您希望與之通信的實際服務器。這就是爲什麼你必須總是檢查證書是有效和可信的。
3. 可能是正確的
4. 如果您確定安全連接是可信的，那麼將安全地發送用戶名/密碼。

Answer 4

首先，我會簡單地描述驗證過程，因爲我理解它，也許我誤會了這一步。因此，客戶端啓動連接，服務器使用公鑰，某些元數據和可信機構的數字簽名進行響應。

服務器響應X.509證書鏈和使用自己的私鑰簽名的數字簽名。

然後客戶端採取的決定，如果她信任的服務器

正確的。

用公鑰加密一些隨機會話密鑰並將其發回。

否。客戶端和服務器參與相互會話密鑰生成過程，從而根本不會傳輸會話密鑰本身。

此會話密鑰只能用存儲在服務器上的私鑰解密。

號

服務器執行此

號

然後HTTPS會話開始。

TLS/SSL會話開始，但是先有更多步驟。

所以，如果我上面說得對，問題是在這種情況下中間人攻擊會如何發生？

僞裝成服務器並充當SSL端點。客戶必須省略任何授權步驟。可悲的是，大多數HTTPS會話中唯一的授權步驟是主機名檢查。

我的意思是，即使有人攔截服務器（例如www.server.com）與公鑰的迴應，然後用一些手段讓我覺得他是www.server.com，他仍然不會能夠在沒有私鑰的情況下解密我的會話密鑰。

參見上文。沒有會話密鑰解密。 SSL連接本身是安全的，它與對話的可能不安全。

說到相互身份驗證，是不是關於服務器對客戶端身份的信心？我的意思是，客戶端可以確定她正在與正確的服務器進行通信，但現在服務器想要查明誰是客戶端，對嗎？

正確的。

最後一個問題是關於替代的相互認證。如果我在所描述的情況下充當客戶端，那麼在SSL會話建立之後，如果我在HTTP頭中發送登錄名/密碼，該怎麼辦？正如我所看到的，這些信息不能被攔截，因爲連接已經安全並且服務器可以依靠它來進行識別。我錯了嗎？

號

什麼是相互驗證這種比較方法的缺點（唯一的安全問題是重要的，而不是實現的複雜性）？

它只是和用戶名/密碼一樣安全，比私鑰更容易泄漏。

Answer 5

任何客戶端和服務器之間的道路上可以暫存在HTTPS的中間人攻擊。如果你認爲這是不可能或很少見，認爲there are commercial products系統地解密，跨互聯網網關掃描和重新加密所有 SSL流量。他們的工作方式是向客戶端發送一個ssl證書，該證書可以與從「真實」ssl證書複製的詳細信息一起創建，但是使用不同的證書鏈進行簽名。如果該鏈終止於任何瀏覽器的可信CA，則該MITM將對用戶不可見。這些產品主要銷售給公司以「保護」（警察）公司網絡，並且應該在用戶的知識和同意的情況下使用。但從技術上講，沒有任何東西阻止他們使用ISP或任何其他網絡運營商。 （假設NSA has at least one trusted root CA signing key是安全的）

如果您正在提供一個頁面，you can include an HTTP header指示頁面應該簽名的公鑰。這可能有助於提醒用戶MITM他們的「安全」連接，但它是首先使用的信任技術。如果鮑勃還沒有「真實」公共密鑰引腳的記錄，Mallory就會重寫文檔中的pkp頭。使用這種技術的網站列表令人沮喪地很短。它包括谷歌和Dropbox，以他們的信譽。

關於密碼，https連接上的所有內容都由https保護，域名除外，因此域名必須清晰，以便請求能夠路由。一般來說，建議不要將密碼放在查詢字符串中，他們可以在日誌，書籤等中逗留。但除非https被泄露，否則查詢字符串不可見。