該篇主要講https中間人攻擊。
伺服器向客戶端傳送公鑰。
攻擊者截獲公鑰，保留在自己手上。
然後攻擊者自己生成乙個【偽造的】公鑰，發給客戶端。
客戶端收到偽造的公鑰後，生成加密hash值發給伺服器。
攻擊者獲得加密hash值，用自己的私鑰解密獲得真秘鑰。
同時生成假的加密hash值，發給伺服器。
伺服器用私鑰解密獲得假秘鑰。
fiddler就是通過這種方式截獲https資訊。
上面問題的根源是因為「缺乏身份認證機制」，瀏覽器無法鑑別自己收到的金鑰是不是真的來自於**伺服器。
假如具備某種【可靠的】身份認證機制？
★身份認證的幾種方式
*基於共同的私密資訊
有個人陌生人突然給你發了一封電子郵件，說他是你的老朋友，那麼你怎麼確保發郵件的人確實是你的老朋友捏。
你可以用郵件向對方詢問一些共同的私密事情。如果對方能夠回答出來，那麼他很有可能是你的老朋友。
*基於雙方信任的公證人
比如有個客人來拜訪你，但是你也不知道來的人是不是他，那就看他的身份證即可。這
就是國家公安部信用作為公證人，讓陌生人建立某種程度信任關係。
★如何解決 ssl 的身份認證問題——ca 的引入
由於雙方通常都是互不相識的，顯然不可能採用第一種方式，而只能採用第二種公證人方式。
那麼，誰來充當這個公證人？這時候，ca 就華麗地登場啦。
瀏覽器驗證**發過來的證書。如果發現其中有詐，瀏覽器會提示「ca 證書安全警告」。
由於有了這一步，就大大降低了（注意：是「大大降低」，而不是「徹底消除」）前面提到的「中間人攻擊」的風險。
為啥瀏覽器能發現 ca 證書是否有問題？
因為正經的 ca 證書，都是來自某個權威的 ca。如果某個 ca 足夠權威，那麼主流的作業系統（或瀏覽器）會內建該 ca 的「根證書」。
（比如 windows 中就內建了幾十個權威 ca 的根證書）
因此，瀏覽器就可以利用系統內建的根證書，來判斷**發過來的 ca 證書是不是某個 ca 頒發的。
此文到此結束！
Https中間人攻擊
https也不是絕對安全的，如下圖所示為中間人劫持攻擊，中間人可以獲取到客戶端與伺服器之間所有的通訊內容。中間人擷取客戶端傳送給伺服器的請求，然後偽裝成客戶端與伺服器進行通訊 將伺服器返回給客戶端的內容傳送給客戶端，偽裝成伺服器與客戶端進行通訊。通過這樣的手段，便可以獲取客戶端和伺服器之間通訊的所有...
Https中間人攻擊
防範方法 一 https連線過程及中間人攻擊原理 https協議就是http ssl協議，如下圖所示為其連線過程 1.https請求 客戶端向服務端傳送https請求 2.生成公鑰和私鑰 服務端收到請求之後，生成公鑰和私鑰。公鑰相當於是鎖，私鑰相當於是鑰匙，只有私鑰才能夠開啟公鑰鎖住的內容 3.返回...
HTTPS攻擊（SSL TLS中間人攻擊）
攻擊機 kali 目標機 win7 攻擊前提 客戶端已經信任偽造證書頒發機構 攻擊者控制了核發證書頒發機構 客戶端程式禁止了顯示證書錯誤告警資訊 攻擊者已經控制客戶端，並強制其信任偽造證書。角色 客戶端 客戶路由器 真實伺服器 攻擊者 伺服器 攻擊者 伺服器 攻擊者通過arp欺騙客戶端通過攻擊者做閘...