最近在网上看到一篇解析https原理的文章, 说的很是透彻清晰, 为防止自己忘记, 在这里自己记录一下. 原文传送门-->
在https
协议出现以前, 基于http
协议传输的数据都是以, 明文的形式裸奔的, 第三方很容易就能拦截, 窃听,篡改或者冒充. http
向https
进化的过程, 可以模拟成以下几步:
- 对称加密
Client -------------- Server
① 对称加密
| -----------> | 解密
② 对称加密
解密 | <----------- |
客户端(Client
)和服务端(Server
)使用对称加密算法(DES
, 3DES
, AES
)等, 在传输前对数据进行加密, 等待对方解密. 但是这种方式跟明文裸奔没什么区别, 因为需要对外暴露对称算法的钥匙
- 非对称加密
Client ---- 🐶 ---- Server
① 公钥加密
| ------> | 私钥解密
② 私钥加密
公钥解密 | <------ |
采用非对称加密只需要对外暴露同一把公钥
, 客户端使用公钥
加密, 使得第三方(🐶)无法窃听数据, 服务端使用私钥
解密, 服务端再使用私钥
加密, 🐶无法冒充, 客户端使用公钥
解密.
这种方式解决了一些问题, 但是还有一定的风险存在:
- ①时, 🐶虽然无法窃听数据, 但是可以用暴露的
公钥
去重新生成数据, 达到篡改的目的. - ② 时, 🐶没法用
公钥
去伪造数据, 但是却能够通过公钥
来窃听服务端返回的数据.
虽然解决了冒充的问题, 但是🐶还是能够进行窃听和篡改.
- 终极方案:对称加密和非对称加密结合
Client ------- 🐶 -------- Server
① 公钥加密[对称密匙]
| --------------> | 私钥解密获取对称密匙
② 私钥加密一段校验数据
公钥和对称密匙确认 | <-------------- |
③ 对称加密
| --------------> | 对称解密
④ 对称加密
对称解密 | <-------------- |
客户端使用
公钥
对对称加密使用的密匙
和某个随机字符串
进行加密
, 第三方无法窃听这个密匙
, 也无法进行伪造篡改. 服务端通过私钥
解密, 得到对称加密的密匙
, 和随机字符串;服务器生成一段
校验数据
, 例如先通过对称密匙
加密随机字符串, 再通过私钥
对结果进行加密, 这样第三方即便拦截到数据, 并用公钥
解密, 获取的数据也完全看不懂, 无法进行窃听. 客户端用公钥
和对称密匙
对数据进行解密, 核对传输内容, 确认服务器可信.接下来, 双端就可以通过
对称加密
进行通信了