中间人

这个问题的场景是这样的：客户端通过浏览器向服务端发起 HTTPS 请求时，被“假基站”转发到了一个“中间人服务器”，于是客户端是和“中间人服务器”完成了 TLS 握手，然后这个“中间人服务器”再与真正的服务端完成 TLS 握手。 具体过程如下：客户端向服务端发起 HTTPS 建立连接请求时，然后被“假基站”转发到了一个“中间人服务器”，接着中间人向服务端发起 HTTPS 建立连接请求，此时客户端与中间人进行 TLS 握手，中间人与服务端进行 TLS 握手； 在客户端与中间人进行 TLS 握手过程中，中间人会发送自己的公钥证书给客户端，客户端验证证书的真伪，然后从证书拿到公钥，并生成一个随机数，用公钥加密随机数发送给中间人，中间人使用私钥解密，得到随机数，此时双方都有随机数，然后通过算法生成对称加密密钥（A），后续客户端与中间人通信就用这个对称加密密钥来加密数据了。 在中间人与服务端进行 TLS 握手过程中，服务端会发送从 CA 机构签发的公钥证书给中间人，从证书拿到公钥，并生成一个随机数，用公钥加密随机数发送给服务端，服务端使用私钥解密，得到随机数，此时双方都有随机数，然后通过算法生成对称加密密钥（B），后续中间人与服务端通信就用这个对称加密密钥来加密数据了