前言
由于之前的文章已经介绍过了HTTP , 这篇文章介绍 HTTPS 相对于 HTTP 做出的改进
开门见山:
HTTPS 是对 HTTP 的加强版
主要是对一些关键信息 进行了加密
一.两种加密方式
1.对称加密
公钥 + 明文 = 密文
密文 + 公钥 = 明文
2.非对称加密![](https://file.jishuzhan.net/article/1769317128877379585/b071c13515b9a15dee855377bafc1870.webp)
举个例子就好比 小区邮箱
提供一把锁(公钥,是给邮递员的) ,和一把钥匙(私钥,自己吃有)
邮递员把你的信,通过这把锁,锁到你的信箱里(使用公钥加密)
然后你就可以拿着你的钥匙打开邮箱(使用私钥解密)
前提是 锁 和 钥匙 是配对的(也就是公钥和私钥是配对的)
二.HTTPS的工作过程
总的目标:针对HTTP 这里的 header 和 body 进行加密
1.对称加密
![](https://file.jishuzhan.net/article/1769317128877379585/1f8c9d2ecb69bf11bd396ae6613ab58e.webp)
但是上图有个很明显的问题,客服务器如果给很多的客户端发对接,那么这些客户端拿的是同一个 密匙 吗?
很明显,必须要求这些客户端的密匙是不一样的,这样彼此才不知道对方的密匙是什么。
那么此时就要求每个客户端的密钥都不同,就需要每个客户端在和服务器进行连接的时候,把自己的密钥生成出来,客户端再通过网络发送给服务器
但是如果黑客把密钥进行了抓取,那么加密操作就形同虚设
![](https://file.jishuzhan.net/article/1769317128877379585/5eb8d1b551ff1de8ca0528bef4d91c0e.webp)
那么如何进行解决呢,如果给密钥套上一层密钥可以吗?答案按是不行的,套多少次都会被截取。
2.非对称加密
跟前面说的一样 , 使用公钥和私钥,也就是对称密钥!!
![](https://file.jishuzhan.net/article/1769317128877379585/cb815cc64f43f1580919f023a57eb6bf.webp)
就是客户端和服务器都生成自己的公钥和私钥
1.客户端给服务器发送一条请求,专门要服务器的公钥
2.服务器把私钥藏好,把公钥给客户端(公钥可能被劫持), 客户端使用公钥进行加密,再进行传输的时候,即使被黑客进行劫持,但是只有私钥才能解密,而私钥在服务器哪里!
3.服务器手里持有私钥,服务器可以对对称密钥进行解密,然后就可以得到了原始的对称密钥。
这里有个问题:既然已经引入了非对称加密,那么为什么还要引入对称加密呢?
答案就是:效率。每个业务逻辑要求的是不一样的,引入非对称加密势必会影响到整体的性能, 也就是在合适的场景下使用非对称加密。对称加密也有他自己的用武之地。
3.中间人问题
非对称加密其实还有一个比较隐蔽的问题,那就是中间人问题
![](https://file.jishuzhan.net/article/1769317128877379585/0dd87f481cfb7ac3a922a27d04cda7d2.webp)
总的来说就是
- 黑客 把pub1 进行获取 , 然后使用 自己的 pub 2 发给客户端,
- 客户端信以为真,使用 pub2 进行加密转给了黑客,黑客使用 自己的 pri2 进行解密之后 , 拿到了关键的对称密钥。
- 还不算完,为了不让服务器发现,黑客还把这个对称密钥使用之前获取的 pub1 加密,发给了服务器。
- 服务器以为是客户端发来的,那么就使用了pri 2 进行解密,得到了对称密钥。
- 此时,三者都有了对称密钥,那么客户端和服务器之间的通信,就非常危险了!
🎈那么如何进行解决呢?
---------->答案就是引入公证机构
服务器再创建的时候,需要先向公证机构进行申请。公证机构根据服务器的一些属性颁发 证书,证书中包含 网站域名,服务器公钥,过期时间,数字签名(被加密后的校验和)等。服务器就会保存好这个证书。
数字签名就是公证机构针对证书中的各个属性,计算出一个校验和,然后使用自己的私钥进行加密。
公证机构会生成自己的公钥和密钥。公钥通过操作系统分发给各个服务器,私钥自己进行保存。
当两者再次进行通信的时候,客户端收到服务器的证书,然后使用内置的公钥进行解密出数字签名,如果发现一致,那么就意味着服务器的证书是公证机构颁发的,是可信的! 因为服务器的数字签名是通过公证机构的对称密钥进行加密的。
总的来说:
https进行加密:
- 对称加密,加密业务数据
- 非对称加密,加密对称密钥
- "中间人"攻击,发现问题!
- 使用证书,校验服务器的公钥