HTTPS 的加密流程
HTTPS 的加密流程
- .
- 对称加密
- 非对称加密
- 中间人攻击
- 引入证书
.
对称加密
最简单的保护http里面数据的安全,就是引入对称密钥,即针对传输的数据(http的header和body)进行加密
对称加密其实就是通过同一个 “密钥” , 把明文加密成密文, 并且也能把密文解密成明文.
黑客手里截获到的数据,是加密后的数据,黑客手里没有对称密钥,就无法进行解密
但事情没这么简单. 服务器同一时刻其实是给很多客户端提供服务的. 这么多客户端, 每个人用的秘钥都必
须是不同的(如果是相同那密钥就太容易扩散了, 黑客就也能拿到了). 因此服务器就需要维护每个客户端
和每个密钥之间的关联关系, 这也是个很麻烦的事情~
比较理想的做法, 就是能在客户端和服务器建立连接的时候, 双方协商确定这次的密钥是啥~
这里的每个客户端,都需要有一把自己的对称密钥,不同客户端的密钥也要不同
如果客户端生成了密钥,就需要把密钥传输给服务器,但是如果直接把密钥明文传输, 那么黑客也就能获得密钥了~~ 此时后续的加密操作就形同虚设了
此时,如上图,黑客就能轻易的获取到密钥的内容了,黑客就可以通过密钥将密文给解密,得到真正的明文,后续使用这个密钥加密传输,传输的数据还是能被黑客截获
因此密钥的传输也必须加密传输!显然,对密钥的加密就不能使用对称加密了,那么我们就需要引入一个非对称加密
非对称加密
非对称加密要用到两个密钥, 一个叫做 “公钥”, 一个叫做 “私钥”.
公钥和私钥是配对的. 最大的缺点就是运算速度非常慢，比对称加密要慢很多
通过公钥对明文加密, 变成密文
通过私钥对密文解密, 变成明文
也可以反着用
通过私钥对明文加密, 变成密文
通过公钥对密文解密, 变成明文
服务器生成公钥和私钥,并将公钥发送给客户端
客户端在本地生成对称密钥, 通过公钥加密, 发送给服务器.
由于中间的网络设备没有私钥, 即使截获了数据, 也无法还原出内部的原文, 也就无法获取到对称密
钥
服务器通过私钥解密, 还原出客户端发送的对称密钥. 并且使用这个对称密钥加密给客户端返回的响
应数据.
后续客户端和服务器的通信都只用对称加密即可. 由于该密钥只有客户端和服务器两个主机知道, 其
他主机/设备不知道密钥即使截获数据也没有意义
由于对称加密的效率比非对称加密高很多, 因此只是在开始阶段协商密钥的时候使用非对称加密,
后续的传输仍然使用对称加密.
此处的非对称加密,只会对密钥进行加密,不会对http的header和body进行加密,因为其效率很低,而对称加密的效率要高不少.
中间人攻击
解决中间人攻击的关键,需要让客户能够确认当前是收到的公钥确实是服务器返回来的,而不是黑客伪造的
引入证书
这个证书包含了刚才的公钥(会分发给其他的各种设备)不是通过网络传输的,而是通过直接的系统内置的,客户端安装了Windows系统,系统里就会内置各种知名公证机构的公钥(黑客没法对这个环节进行中间人攻击), 也包含了私钥和网站的身份信息
通过第三方的认证机构作保,来确认当前的公钥是有效的
这个 证书 可以理解成是一个结构化的字符串, 里面包含了以下信息:
证书发布机构
证书有效期
公钥
证书所有者
数字签名:
针对上述数据进行的一个验证的机制,公证机构,在生成证书的时候,会先对证书中的其他属性,生成校验和,公证机构还会使用自己的私钥(不少服务器的私钥),针对上述的校验和进行加密,这样别人就无法重新生成校验和
客户端在拿到证书之后,就会对证书进行验证(检查一些证书是否合法,是否被篡改过)
客户端手里持有认证机构的公钥,就可以针对数字签名进行解密,得到了校验和明文,接下来客户端就可以按照同样的算法,把证书中的其他属性再算一次校验和,和证书中解密出来的校验和进行对比,如果一致,说明证书安全,如果不一致,说明证书被篡改了