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

问题本质出在哪里了呢？客户端无法确定收到的含有公钥的数据报文，就是⽬标服务器发送过来的！