HTTPS應用層協議-中間攻擊人

? Man-in-the-MiddleAttack，簡稱“MITM 攻擊”

確實，在方案 2/3/4 中，客戶端獲取到公鑰 S 之后，對客戶端形成的對稱秘鑰 X 用服務端給客戶端的公鑰 S 進行加密，中間人即使竊取到了數據，此時中間人確實無法解出客戶端形成的密鑰 X，因為只有服務器有私鑰 S’

但是中間人的攻擊，如果在最開始握手協商的時候就進行了，那就不一定了，假設hacker 已經成功成為中間人

1. 服務器具有非對稱加密算法的公鑰 S，私鑰 S’

2. 中間人具有非對稱加密算法的公鑰 M，私鑰 M’

3. 客戶端向服務器發起請求，服務器明文傳送公鑰 S 給客戶端

4. 中間人劫持數據報文，提取公鑰 S 并保存好，然后將被劫持報文中的公鑰 S 替換成為自己的公鑰M，并將偽造報文發給客戶端

5. 客戶端收到報文，提取公鑰 M(自己當然不知道公鑰被更換過了)，自己形成對稱秘鑰 X，用公鑰 M 加密 X，形成報文發送給服務器

6. 中間人劫持后，直接用自己的私鑰 M’進行解密，得到通信秘鑰X，再用曾經保存的服務端公鑰S 加密后，將報文推送給服務器

7. 服務器拿到報文，用自己的私鑰 S’解密，得到通信秘鑰 X

8. 雙方開始采用 X 進行對稱加密，進行通信。但是一切都在中間人的掌握中，劫持數據，進行竊聽甚至修改，都是可以的上面的攻擊方案，同樣適用于方案 2，方案 3

問題本質出在哪里了呢？客戶端無法確定收到的含有公鑰的數據報文，就是?標服務器發送過來的！