我試圖了解中間人攻擊將如何影響我的網頁伺服器。
我有一個自簽名憑證。這個憑證可以透過中間人攻擊來偽造，這意味著我從瀏覽器發送的所有內容都會被攔截和修改？
如果請求被修改，則 Web 伺服器不會對其進行解密，因為伺服器上的憑證不同。它是否正確？
從瀏覽器發送的請求可以被攔截並可能被重定向，但我伺服器上的資料不會受到影響，這是正確的嗎？
我開始了解證書背後的理論，但如果有人能夠提供中間人攻擊的真實範例並看看它造成了什麼問題，那就太好了。
謝謝
答案1
正如我在先前的回答中所說你的問題，中間人攻擊（如果成功）可以擁有加密通道來回傳遞的所有資料。
自簽名證書和從受信任根頒發的證書都可以偽造，因此，如果您從受信任根向用戶頒發證書，請不要陷入錯誤的安全感。對於由受信任的根發出的問題，我必須克服的唯一問題是當我對他們的計算機進行 arp 毒害時，讓你的用戶接受我的。如果您考慮大多數最終用戶，這有多容易？
現在你能看到問題所在嗎？
一旦最終用戶接受我的證書，我就擁有從那時起的連接，並且所有資料都通過我的機器。
答案2
基本上發生的情況是您已經自簽署了您的證書，因此您無法證明它是有效的。所以它可以很好地加密流量，但你無法證明它是你的。如果駭客可以進入您的網站和使用者的電腦之間並攔截流量，他就可以解密流量並讀取正在發生的情況。 （他也可以透過註冊與您的網域相似的網域名稱並等待拼字錯誤或發送電子郵件將他們引導至他的網站而不是您的網站來實現此目的）
User ****** Hacker **** Your website
他能做到這一點的原因是他也可以提供自簽名證書。那麼用戶實際上是在與駭客而不是你進行通訊。用戶無法區分。事實上，如果他想要，駭客可以重新加密流量並將其發送回您的站點，並使用使用者憑證啟動他自己的與您的站點的通訊流。或只是在清晰的情況下觀察來回移動的交通。
答案3
並不是說他可以修改流量。 SSL 握手開始時未加密，伺服器傳送 SSL 憑證供用戶端從那時起使用。如果攻擊者從一開始就在那裡，他可以用自己的證書替換這個初始證書，然後使用伺服器發送的證書來加密/解密往返伺服器的流量，並使用他自己的證書將其發送給您。
如果憑證是由憑證授權單位簽署的，則用同樣由 CA 簽署的假憑證取代它會有點困難。然而，攻擊者可以輕鬆地用自簽名證書替換該證書，因此會出現警告。
答案4
驗證證書時需考慮兩點：
- 驗證它是由您信任的實體發出的，並且
- 驗證它是否與您嘗試聯絡的伺服器的身份相符。
CA所核發的憑證
這使用 X.509 憑證的公鑰基礎架構。規格定義為此設定的結構。這是一個分層模型，您可以在其中獲得一棵樹，其根是憑證授權單位 (CA)，其葉子是最終實體憑證（特別是伺服器憑證）。
根 CA 憑證往往是自簽署的。預設情況下，您的作業系統或瀏覽器包含其中的一堆。這就是「信仰的飛躍」部分，您相信您的作業系統/瀏覽器供應商已經審查了 CA，使其能夠正確完成工作。一些大型商業 CA 包括 Verisign、Thawte…
然後，CA 可以簽署其他憑證。您可以透過檢查您以前從未見過的憑證是否由您信任的 CA 簽署來驗證該憑證。也可能存在中間 CA。例如，證書為https://www.google.com/已由“簽署”索特 SGC CA”，其本身已由“簽署VeriSign, Inc./3 級公共主要憑證授權單位（為了簡化起見，我在這裡縮寫了名稱）www.google.com。所不同，對於非EV 證書，通常只需向註冊網域的地址發送電子郵件即可完成（可在誰是目錄）。
完成此操作後，假設您不知道是否信任https://www.google.com/，用戶端將根據其擁有的信任錨（CA，通常由作業系統/瀏覽器供應商預先匯入）驗證此憑證。如果您連接到www.google.com，瀏覽器會取得證書，然後能夠計算出一直到頂級頒發者的鏈（每個證書中都有一個頒發者條目），直到找到它信任的證書（在本例中是來自Verisign 的證書）。到目前為止，一切順利，證書是可信的。第二步包括檢查該證書是否確實適用於該機器。對於 HTTPS，這是透過檢查主機名稱是否位於憑證的使用者備用名稱擴充功能中來完成的，或者作為後備，檢查主機名稱是否位於使用者專有名稱的「通用名稱」(CN) 條目中。這在中進行了解釋RFC 2818（伺服器身分）。
這裡可能的攻擊嘗試如下：
- 攻擊者使用自己的 CA 偽造憑證（無論是否針對該主機名稱）。由於您的瀏覽器無法識別他們的 CA，因此不會驗證憑證。即使他們偽造了頒發者名稱，他們也無法偽造簽名（因為您使用您已經信任的 CA 憑證使用公鑰進行驗證）。這裡最大的問題之一是簽名的強度：已經使用 MD5 摘要演算法演示了衝突攻擊，因此 CA 現在使用 SHA-1，這被認為更穩健。如果您認為 RSAwithSHA1 或 DSAwithSHA1 足夠穩健，那麼您應該不會遇到問題。
- 攻擊者從知名 CA 取得合法證書，但使用不同的主機名稱（因為 CA 不應向其他人發送）。假設他們得到了
www.example.com.當您嘗試連接到 時www.google.com，他們會將流量重定向到他們的盒子，該盒子將顯示一個可以由您信任的 CA 驗證的證書，但是對於www.example.com.這就是主機名稱驗證很重要的地方。您的瀏覽器會警告您尚未連接到您想要的主機。
該系統旨在確保，如果 MITM 將流量重定向到其計算機，客戶端將不會接受連線。當然，只有當使用者不忽略瀏覽器顯示的警告時，這才有效。
自簽名證書
原理是一樣的，只不過你是CA，這個自簽名憑證也可能直接是伺服器憑證。如果您建立自己的自簽名憑證並將其放在您的電腦上，您也可以將其作為受信任的頒發機構匯入瀏覽器中，在這種情況下，您需要遵循與上述相同的流程。
有些瀏覽器（例如 Firefox）允許您為這些規則添加永久例外。如果您透過其他方式（例如管理員親自向您提供了憑證）知道您要連接的電腦的憑證是什麼，您可以選擇明確信任它們，即使它們尚未經過簽署您信任的 CA 或名稱不符。當然，為此，您確實需要先驗且明確地知道該特定證書應該是什麼。
如果在任一情況下，使用者選擇忽略警告並接受重定向到具有不受信任證書的連接，則 MITM（具有該不受信任證書）可以查看/重定向/更改流量。