最近在网上看到一篇解析https原理的文章, 说的很是透彻清晰, 为防止自己忘记, 在这里自己记录一下. 原文传送门-->
在https协议出现以前, 基于http协议传输的数据都是以, 明文的形式裸奔的, 第三方很容易就能拦截, 窃听,篡改或者冒充. http向https进化的过程, 可以模拟成以下几步:

加密算法传送门-->

1. 对称加密

Client   --------------   Server
                ① 对称加密
              | ----------->   |  解密
                ② 对称加密
  解密   |  <-----------  |

客户端(Client)和服务端(Server)使用对称加密算法(DES, 3DES, AES)等, 在传输前对数据进行加密, 等待对方解密. 但是这种方式跟明文裸奔没什么区别, 因为需要对外暴露对称算法的钥匙

2. 非对称加密

    Client  ---- 🐶 ----  Server
                    ① 公钥加密      
                    |     ------>   | 私钥解密
                    ② 私钥加密
公钥解密  |    <------    |

采用非对称加密只需要对外暴露同一把公钥, 客户端使用公钥加密, 使得第三方(🐶)无法窃听数据, 服务端使用私钥解密, 服务端再使用私钥加密, 🐶无法冒充, 客户端使用公钥解密.

这种方式解决了一些问题, 但是还有一定的风险存在:

• ①时, 🐶虽然无法窃听数据, 但是可以用暴露的公钥去重新生成数据, 达到篡改的目的.
• ② 时, 🐶没法用公钥去伪造数据, 但是却能够通过公钥来窃听服务端返回的数据.
  虽然解决了冒充的问题, 但是🐶还是能够进行窃听和篡改.

3. 终极方案:对称加密和非对称加密结合

                                      Client  ------- 🐶 --------  Server
                                                ① 公钥加密[对称密匙]    
                                          |     -------------->   | 私钥解密获取对称密匙
                                                ② 私钥加密一段校验数据
公钥和对称密匙确认 |     <--------------   |
                                                 ③ 对称加密   
                                           |     -------------->   | 对称解密
                                                ④ 对称加密
        对称解密                 |     <--------------   |

• 客户端使用公钥对对称加密使用的密匙和某个随机字符串进行加密, 第三方无法窃听这个密匙, 也无法进行伪造篡改. 服务端通过私钥解密, 得到对称加密的密匙, 和随机字符串;

• 服务器生成一段校验数据, 例如先通过对称密匙加密随机字符串, 再通过私钥对结果进行加密, 这样第三方即便拦截到数据, 并用公钥解密, 获取的数据也完全看不懂, 无法进行窃听. 客户端用公钥和对称密匙对数据进行解密, 核对传输内容, 确认服务器可信.

• 接下来, 双端就可以通过对称加密进行通信了