也可以说是https>https传输流程（加密方式、证书、传输安全）
目录：
- CA证书的签发流程：CA证书的签发流程详情_燚湫的博客-CSDN博客_ca颁发证书
- 需要明白证书包含了哪些内容
- https>https传输流程：https>https传输流程（加密方式、证书、传输安全）_短暂又灿烂的的博客-CSDN博客_https>https传输
上述整个流程是前面通信用的是证书的公私钥的非对称加密，后面数据传输用的秘钥是随机的对称加密的秘钥
问题：
-
https>https传输过程中中间人能否篡改证书的公钥和证书签名？
由于每个CA公钥是公开的，所以中间人也有，能够揭秘获取到服务器公钥和证书签名，中间人如果想修改这两个数据，则需要用中间人自己的私钥进行加密，但是client会用CA公钥解密，自然是解不开的，所以无法篡改。 -
中间人能否篡改证书的域名？
验证签名的过程会出错，因为client需要将域名、 CA公钥、 自己公钥用hash算法生成一个签名，再和证书上的签名对比，此时发现不一致，则说明域名、 CA公钥、 自己公钥被篡改过了。 -
中间人能否在client请求证书时就拦截，并返回一个中间人自己的证书？
其实是可以的，但需要得到client的同意，信任此证书才行。这也是抓包工具可以截取到https>https传输过程中数据的原因。但也会有第三方利用这一点，出现个弹窗诱导用户点击，就可以给client植入“木马病毒”，这样就能获取和篡改client和server的数据。 -
为什么 https>https 不直接使用服务端的公钥对数据信息进行加密，而是使用公钥先对密钥加密，之后再用密钥对数据信息加密的方式呢？
我们知道 https>https 采用的是非对称密钥和对称密钥混合加密机制，若仅仅使用非对称加密，即仅仅使用服务端提供的公钥来加密可行吗，理论上同样也可以，但是不好，其处理速度比对称密钥要慢很多，网上统计是对称加密算法比非对称加密算法快大约1500倍。所以这下就清楚了，在请求服务器的最开始阶段，我们通过非常安全的非对称密钥技术，服务端将公钥交给浏览器（里头涉及数字证书以及公钥进行解密的过程），这一步其实挺慢的，但是好在只用在开头执行一次，之后如果依旧使用这个公钥对数据信息加密和服务器私钥对数据信息解密，这就太慢了，所以后序我们使用更加快速的对称密钥技术，用公钥对密钥加密给服务端，即使中间人截取了数据，由于没有私钥所以也没法对工要加密的数据进行解密，这样就保证了对称密钥的安全性，因此也就可以保证以后传输数据信息使用对称密钥加密不怕被窃取
