阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 blog.csdn.net/qq_65228171/article/details/130840752 「爱吃大白菜」欢迎转载，保留摘要，谢谢！

• 1 没有加密的时候
• 2 对称密钥加密传输
• 3 非对称加密
• 4 引入数字证书（对称加密+非对称加密）

---

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

既然要对HTTPS进行解读，我们首先了解，HTTPS是什么？

HTTPS就相当于HTTP+SSL/TLS这样的组合，HTTP（超文本传输协议），HTTP是tcp/ip组中的协议之一运用在应用层，也是互联网上应用最为广泛的协议之一，所有的WWW（万维网）文件都必须遵循这个标准。而设计HTTP协议的最终目的是用来在互联网上传输HTML文件，而SSL/TLS就是一种加密算法。

下面会对HTTPS加密的进化过程进行解析。

1 没有加密的时候

这个时候，客户端与服务器之间都已明文的方式传输，你只要在中间截取到数据，就可以看到客户端和服务器在干些什么。

这样做是比较方便、节约成本，但是我们在传输过程中全以明文方式传输，谁都可以看的见，谁都可以看的懂；如果我们这传输的是金钱交易，很容易就被黑客劫持，让黑客篡改了数据。故有了下面对称密钥加密的方式传输。

2 对称密钥加密传输

对称密钥加密传输是客户端先生成一个密钥，客户端发送数据时，先使用密钥给明文加密，让他变成密文，在将密文和密钥传输给服务器，服务器再通过客户端发送的密钥进行解密得到明文。

对称密钥加密能解决传输中的安全问题吗？显然是不能的。在客户端生成密钥之后，我们是要将密钥发送给服务器的，这样服务器有了密钥才可以对客服端发送的密文解密，在这个过程中，密钥是经过传输才能到达服务器，如果在传输过程中被黑客劫持了，那么黑客也可以通过密钥将密文解密了。

既然对称加密无法破解，那就再引入一个新的加密方法:非对称加密。

3 非对称加密

非对称加密是服务器生成两个密钥，我们称这两个密钥：一个公钥（pub）、一个私钥（pri）；他两个是一对，用公钥加密的数据，必须用私钥才能解密；用私钥加密的数据，必须用公钥解密。

客户端在发送数据时，先给服务器大哥要公钥，客户端拿到公钥后，使用公钥加密完数据再发给服务器，服务器通过与公钥配对的私钥进行解密，这样就算在中间遇见了黑客截取数据，我们也不怕，因为黑客就算拿到了公钥和数据，黑客也无法使用公钥对数据解密。

非对称加密是否安全呢？这里的答案还是不安全；黑客这时使用“来骗来偷袭”的阴险招式来放到客户端这个老同志。

客户端在给服务器大哥要公钥，当服务器发来公钥时，黑客来了一个偷梁换柱、暗度陈仓将服务器的公钥A换成了公钥B，黑客将公钥B发送给了客户端，客户端就有公钥B进行加密数据，发送给服务器，黑客再次截取，通过私钥B将数据解密，之后再用公钥A加密发给服务器大哥，就这样黑客神不知鬼不觉就将数据拿到了手。在个期间，黑客手中有公钥A、公钥B和私钥B，公钥B和私钥B是黑客自己生成的，公钥A是黑客截取服务器的。

4 引入数字证书（对称加密+非对称加密）

既然上方的方法都不安全，只能再修改了，引入数字证书，数字证书由可信任的第三方权威机构颁发，相当于一个身份证，可以验证服务器的身份。数字证书包含了证书持有者的信息和公钥信息等。

这个过程中一共有五把密钥，一把是客户端生成的对称密钥，用来加密业务数据；服务器生成的非对称密钥公钥A和私钥A用于加密对称密钥；颁布证书机构的非对称密公钥B和私钥B（私钥机构自己持有，公钥客户端电脑系统内置），用来加密证书的签名。

客户端拿到证书之后，首先针对证书进行校验：

• 得到初始的签名： 客户端使用系统中内置的权威机构的公钥（权威机构的公钥内置在操作系统当中），针对证书中的加密签名进行解密，得到初始签名（这个签名是权威机构算出来的设为sum1）；
• 计算现在的签名： 客户端使用相同的签名计算算法，基于证书中的属性重新计算，得到sum2；
• 比较两个签名是否相同： 如果相同，说明证书中的数据是未被修改的原始数据，如果签名不同，说明证书的数据被篡改过，客户端的浏览器就会弹窗报错。

在这个过程中，黑客可以得到我们发送的证书，也可以修改，不过黑客修改过后，客服端在用权威机构的公钥解密后的签名与计算后得到的现有签名会出现不一致，这个时候我们就知道被攻击了。