https协议原理、中间人问题

一、数据传输类型（中间人问题）

1 明文传输：

【问题】相当于裸奔、任何第三方都可拦截数据。

2 对称加密：

【特点】传输的数据是通过加密之后的密文。
【问题】当第三方（中间人） 可以充当客户端、获取到服务器的的加密算法、通过转发的方式来给 真正的客户端 传送数据。同样不安全。
【缺点】key只有一个

3 非对称加密：

服务器有唯一私钥 - 客户端有公钥

【特点】
数据流转如下：
私钥对数据加密、公钥对数据解密。
公钥对数据加密、私钥对数据解密。

【问题】看似安全、但实际 第三方（中间人） 仍然可以请求服务器获取公钥、充当客户端从而来转发数据给 客户端 转发数据，依旧不是安全的。
【破解】只有在客户端向服务端发送数据时是安全的，因为只有服务端有秘钥来解密公钥加密的数据。—— 服务端向客户端发送数据依然存在暴露的风险。

4 非对称加密 + 对称加密：

【特点】客户端第一次通过非对称加密的方式安全向服务器定义一个协商key值，后续传输使用对称加密 + 协商key来进行对称加密传输。—— 这里看来 第三方（中间人） 因为无法拿到对应的协商key值而无法破解拦截的数据，是相对安全的。
【问题】近乎完美
【破解】假如当客户端第一次定义key时，被当 第三方（中间人） 拦截到、那么 第三方（中间人） 仍然可以获取到协商key，然后充当服务端、来转发数据。不安全+1。

二、解决方案（保证获取到客户端的秘钥是绝对的安全性）对称+非对称+CA认证

产生中间人问题的原因是因为，客户端不知道拿到的公钥是好是坏；

利用CA机构来认证公钥和私钥，只有当CA认证的才是正确的、其他的公钥一律被认证为不安全的公钥。

使用非对称加密的方式获取服务端的公匙 客户端请求公匙 服务端通过 CA机构的密匙
（三方）来对服务端的公匙来加密，生成一个加密后的证书。并把这个证书返回给客户端。

客户端操作系统内置了CA的大量的公钥。所以可以直接解密正式，来获取 目标服务端的公钥。

三、过程示例

1、C端发送请求：非对称算法 + 随机数
2、S段响应请求：对称算法 CA +随机数2+证书
3、C端认证证书
4、认真成功后、C端发送随机数3+hash值。