前言
Https=Http+SSL
接下来我们探讨一下https如何保证安全性
逐渐深入，依据加密的不同方法的缺陷 深入去理解加密背后的逻辑
1.对称加密
对称加密就是 客户端生成密钥，通过密钥将明文请求加密为密文
将密文和密钥一起发送给服务端
服务端通过密钥去对密文解析获取到明文请求
但密钥明文传输可能会被黑客获取到
这样的加密逻辑安全性由于密钥是明文传输 容易被获取，在一些安全性要求高的场景下，这样的 加密方式不适用
但是只要保证了密钥的安全性其实对称密钥就狠方便使用
- 加解密速度极快 ：算法逻辑简单（多为分组 / 流加密），计算量小，适合大数据量、高并发的加密场景（如文件、流数据、通信内容加密）。
- 加密效率高：对系统资源（CPU / 内存）消耗低，嵌入式设备、高性能服务端都能轻松适配。
- 密文压缩性好：加密后的密文长度和原文接近，不会产生大量冗余数据，传输 / 存储成本低
2.非对称加密
非对称加密涉及到三种密钥
1.服务端的·公钥
2.客户端的 密钥（对称密钥）key
3.服务端的私钥
主要是通过服务器公钥加密 服务器私钥解密的方式 保证对称密钥的安全性
与对称加密相比之下更安全，但是非对称加密加解密速度超级慢 而且密文特长
但非对称加密 也不是绝对安全 黑客可通过中间人攻击来获取信息
什么是中间人攻击呢？
黑客自身设置一套公钥与私钥 去骗取得到对称密钥key 偷梁换柱
为了解决这样的问题 我们就需要给客户端安排一个孙悟空火眼金睛去判断出公钥是否正确
因此引入了证书这样的机制
黑客此时虽然通过内置的pub2可以看到证书的信息，但是不能修改证书
当它修改证书中服务器公钥和Ip 证书中的数字签名也要去修改，但是数字签名的修改是需要第三方机构的私钥去加密的
如果黑客使用自己的私钥去加密 就会导致客户端使用公钥pub2解密失败 也会提示红色界面 网站不安全是否继续
整个过程最后保证了服务端公钥的正确性，后续获取到对称密钥时就可以继续使用对称加密来进行加密传输
最终，HTTPS 通过这一套流程，确保了通信的三大安全特性：
-
保密性：数据被加密，无法被窃听。
-
完整性：数据有防篡改校验，一旦被修改会被发现。
-
认证性：通过证书验证，确认通信方的身份。