目录
1.HTTPS是什么?
HTTPS 也是一个应用层协议,HTTPS是基于HTTP协议+安全层(SSL/TLS用来加密的协议)实现的
HTTP 协议内容都是按照文本的方式明文传输的,导致在传输过程中出现一些被篡改的情况,由于我们通过网络传输的任何的数据包都会经过运营商的网络设备(路由器, 交换机等), 那么运营商的网络 设备就可以解析出你传输的数据内容, 并进行篡改
前文也说过运营商劫持的问题,为什么要进行这样的篡改呢?说白了还是被金钱蒙蔽了双眼.假如当我们点击 “下载按钮”, 其实就是在给服务器发送了一个 HTTP 请求, 获取到的 HTTP 响应其实就包含了该 APP 的下载链接. 运营商劫持之后, 就发现这个请求是要下载这个APP, 那么就自动的把交给用户的响应给篡改成另外的的下载地址(另一个APP)了,一下载就变成别的了,这样做的原因肯定是这个APP给钱了!!
所以下载要使用的软件一定要去官网上下载!要下载有份概念的软件,可以在虚拟机上下载,因为虚拟机可以随时回退,删除,比较安全
2.解决方案-加密
HTTP是明文传输的,比较危险.为了解决运营商劫持的问题,要进行对数据的加密
加密就是把明文(要传输的信息)进行一系列变换生成密文
解密的过程就是将密文再进行一系列变换还原成明文
在这个加密和解密的过程中,还需要一个或多个中间数据,辅助这个过程,这样的数据称为密钥
所以我们大概可以知道加密解密的过程如图
加密解密也已经发展为独立的学科:密码学
这里还要提到一位大佬,就是密码学的奠基人, 也正是计算机科学的祖师爷之一, 艾伦·麦席森·图灵
3.HTTPS的工作过程
为了保证数据的安全就需要对数据进行加密,网络传输中不再直接明文传输,而是加密之后的密文
加密方式可分为两大类:对称加密和非对称加密
3.1对称加密
先了解一下对称加密
明文a+key=>密文b
密文b+key=>明文a
很明显,对称加密其实就是通过同一个 “密钥” , 把明文加密成密文, 并且也能把密文解密成明文
看一个简单的对称加密, 按位异或
假设
明文:123456
key:123123
加密:
解密:
对称密钥的安全性前提是,密钥不能泄露
由于没有密钥,及时截取了密文,没有密钥解密,也不知道数据是什么意思
那么密钥是谁生成的呢.由于一个服务器对应很多个客户端,因此每个客户端都要有不同的密钥,如果密钥相同,那么和没有一样了..因此服务器还需要维护每个客户端和每个密钥之间的关联关系,也比较麻烦,需要记录每个客户端的密钥..所以为了节省服务器资源,更理想的做法是不进行记录
当客户端和服务器建立连接的时候,双方协定这次使用什么密钥传输数据,过程如图所示
由于第一次服务器也不知道客户端的密钥是什么,需要客户端明文传送密钥给服务器.那么此时如果被截取,密钥就泄露了.因此密钥的传输也必须加密传输!很显然,对密钥加密不能再使用对称加密了
引入了非对称加密
3.2非对称加密
非对称加密要用到两个密钥, 一个叫做 “公钥”, 一个叫做 “私钥”
公钥是公开的,私钥是隐私的.服务器生成一对密钥,客户端持有公钥,服务器私藏私钥
公钥和私钥是配对的. 最大的缺点就是运算速度非常慢，比对称加密要慢很多
非对称加密过程
公钥+明文=>密文
私钥+密文=>明文
或者反过来也可以
非对称加密过程:
客户端先在本地生产对称密钥,然后通过公钥加密,发送给服务器
由于中间网络设备没有私钥,即使截获了数据,也不能还原出明文,获取对称密钥
服务器通过私钥解密,获取对称密钥,并使用对称密钥加密返回给客户端的响应数据
第一次使用非对称加密,确保了对称加密密钥没有泄露.因此后续的客户端服务器通信都使用对称加密即可
注意:由于对称加密的效率比非对称加密高很多, 因此只是在开始阶段协商密钥的时候使用非对称加密, 后续的传输仍然使用对称加密
问题又来了.客户端如何才能获取到公钥呢?我们看下面的场景
3.2.1中间人攻击
这个场景大概就是客户端不知道p2这个公钥是假的,然后还通过p2传输了对称密钥给黑客
黑客拿着对称密钥使用p1公钥进行加密后传给服务器
服务器就使用pri1解密收到的数据,获取到对称密钥,后续通信都以这个密钥进行加密
这也就是中间人攻击问题
解决中间人攻击问题的关键:客户端要能正确的识别公钥是否来自真正的服务器
为了解决这个问题引入了"证书”
3.2.2证书
证书 可以理解成是一个结构化的字符串, 里面包含了以下信息: 证书发布机构 证书有效期 公钥 证书所有者 签名 ……
客户端拿到一个证书会判定:
证书的有效期是否过期
证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构)
证书是否被篡改
在客户端和服务器刚一建立连接的时候, 服务器给客户端返回一个 证书. 这个证书包含了刚才的公钥, 也包含了网站的身份信息,证书本质是一个第三方认证机构提供的,服务器具有合格的条件就能申请证书,服务器生成的密钥也包含在证书中.
此时客户端请求公钥时,是将整个证书都请求过来.客户端拿到证书后就对证书进行校验(验证证书是不是假的或被篡改的.如果证书无效,浏览会弹窗警告)证书上面会有特定的字段,叫做证书的签名.
客户端使用第三方认证机构提供的公钥进行解密,解密后得到的结果相当于一个哈希值,类似于校验和,客户端可以使用同样的哈希算法针对其他字段再算一次哈希值买得到的哈希值如果相同,就说明证书是有效的,没有被篡改
那么黑客能篡改证书么?比如说替换掉公钥?
答案是不行的,一旦替换了公钥,意味着从客户端计算的哈希值和从签名中解密的哈希值不同,客户端就发现证书无效
引入证书后,通信过程:
3.3总结
HTTPS 工作过程中涉及到的密钥有三组
第一组(非对称加密): 用于校验证书是否被篡改. 服务器持有私钥(私钥在注册证书时获得), 客户端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥). 服务器使用这个私钥对证书的签名进行加密. 客户端通过这个公钥解密获取到证书的签名, 从而校验证书内容是否是篡改过
第二组(非对称加密): 用于协商生成对称加密的密钥. 服务器生成这对私钥-公钥, 然后通过证书把公钥传递给客户端. 客户端用这个公钥给生成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解密,获取到对称加密密钥
第三组(对称加密): 客户端和服务器后续传输的数据都通过这个对称密钥加密解密
原文链接: https://blog.csdn.net/chenchenchencl/article/details/129452065