中间人伪装服务器

• 客户端向服务端发起HTTPS建立连接请求时，然后被"假基站"转发到了一个中间人服务器，接着中间人服务器向服务端发起HTTPS建立连接请求，然后客户端与中间人进行TLS握手，中加入与服务端进行TLS握手。
• 在客户端与中间人进行TLS握手过程中，中间人会发送自己的公钥证书给客户端，客户端验证证书真伪，然后从证书中拿出公钥，根据随机算法生成一个随机数，用公钥加密后发送给中间人，中间人使用私钥解密，得到随机数，然后双方根据该随机数，生成对称加密密钥A，后续它们就使用该密钥来进行通信。
• 在中间人与服务端进行TLS握手的过程中，服务端会发送从CA机构签发的公钥证书给中间人，中间人从证书拿到公钥，并生成一个随机数，用公钥加密后发送给服务端，服务端使用私钥解密，得到随机数，然后它们通过算法生成对称加密密钥B，之后它们就使用该密钥来通信。

而后续的通信中，中间人使用密钥A解密客户端的数据，然后使用密钥B加密数据后，发送给服务端，接着服务端发送响应后，中间人使用密钥B解密，然后使用密钥A加密，发送给客户端。

根据上面的情况所知，只要客户端识别出中间人给它发送的公钥是假的就可以了。

首先我们先看看客户端是如何验证证书的？

数字证书签发和验证流程

1. 当服务端向CA机构申请证书的时候，CA签发证书的过程：
   首先CA会把持有者的公钥，用途，颁发者，有效时间等信息打成一个包，然后进行Hash加密，得到一个Hash值

2. 然后CA会使用自己的私钥将该Hash值加密，生成Certificaet Signature，也就是CA对证书做了签名。

3. 最后将Certificate Signature 添加在文件证书上，形成数字证书。

客户端校验服务端数字证书的过程

证书信任链
因为我们向CA申请的证书一般不是根证书签发的，而是由中间证书签发的。
所以当收到对方发送的证书时，发现该证书不是根证书，就无法根据本地已有的根证书的公钥去验证它是否可信，于是客户端去找那个中间证书（即该证书的颁发者），直到找到它根证书，然后查看该证书是否在本地有记录，如果有，则使用本地的公钥去验证它是否可信。

1. 首先客户端会使用同样的Hash算法获取该证书（由对方发来的）的Hash值H1。
2. 通常浏览器和操作系统中都有CA的公钥信息，浏览器收到证书后使用CA的公钥（浏览器或者操作系统存储的公钥）解密Certificate Signature内容，得到一个Hash值H2
3. 最后比较H1和H2，如果值相同，则为可信赖的证书，否则则认为证书不可信。

如何出现中间人伪装服务器成服务器的情况？

根据上面的情况，我们来说一下，什么情况下会出现上面的情况。

1.当访问某个网站时，它的证书可能有问题，然后浏览器会弹出该证书存在问题，是否信任，如果我们点击信任的话，则之后我们的数据就已经被中间人"偷看"了。

2.自己的电脑被植入病毒，该病毒可能会植入中间人的根证书，这种情况下，当访问某些网站时，浏览器是不会弹出该证书存在问题的。

避免该情况

1.防止电脑被植入病毒。
2.一般HTTPS是单向认证，我们可以通过HTTPS双向认证避免这种问题。