HTTPS详解-参考小林coding 小白Debug_在对称加密中,加密和解密使用相同的密钥。这个密钥通常被称为“对称密钥”或“会

本文链接：https://blog.csdn.net/2401_84972980/article/details/138967231

像这种，将一段大家看得懂的信息（明文）转换为另一段大家看不懂的信息（密文），其实就是加密。
像这种“左移”的加密方法，其实就是所谓的秘钥。而这种加密和解密用的都是同一个秘钥的加密形式，就叫对称加密。

对称加密
那既然有对称加密，那就有非对称加密。
不同点在于，非对称加密，加密和解密用到的不是同一个秘钥，而是两个不一样的秘钥，分别是公钥和私钥。

                              ![image.png](https://img-blog.csdnimg.cn/img_convert/7f1d6ce8bb5d495d74368c0ed2ce47f3.png)
                                                                           非对称加密

公钥负责加密，私钥负责解密。公钥人人可得，私钥永远不泄露。

为什么用公钥加密，却不能用公钥解密？

这其中涉及到公钥和私钥加密的数学原理。
加密就是把一个已知的数字根据一定规则转化变为另外一个数字，以前这些数字放一起都可读。但这样一转换，就变得不可读了。就像班花说单词左移就是很简单的转换方式。
我们由欧拉定理对大数取模可以得到一组公式。（不做深究）

原文^(p) mod N = 密文
密文^(q) mod N = 原文

所以知道p能加密，知道q能加密
这里p是公钥，q就是私钥。
** 用公钥加密过的密文只有用私钥能解密。**

p和q在公司位置可以互换，所以反过来锁“用私钥加密过的密文，只有公钥才能解密”，也是对的。这种就是验证数字签名。

所以为什么用公钥加密，却不能用公钥解密？
因为大数取模运算是不可逆的，因此他人无法暴力解密。但是结合欧拉定理，我们可以选取出合适的p（公钥）, q（私钥）, N（用于取模的大数），让原本不可逆的运算在特定情况下，变得有那么点“可逆”的味道。数学原理决定了我们用公钥加密的数据，只有私钥能解密。反过来，用私钥加密的数据，也只有公钥能解密。
从数学原理也能看出，公钥和私钥加密是安全的，但这件事情的前提是建立在"现在的计算机计算速度还不够快"这个基础上。因此，如果有一天科技变得更发达了，我们变成了更高维度的科技文明，可能现在的密文就跟明文没啥区别了。

HTTPS加密的原理

首先看看HTTP和HTTPS的区别

HTTP（HyperText Transfer Protocol）和HTTPS（HyperText Transfer Protocol Secure）是用于在网络上传输数据的两种协议，它们之间有以下主要区别：
安全性：

HTTP是明文传输的，数据在传输过程中不加密，容易被窃听和篡改。
HTTPS通过使用SSL/TLS协议对数据进行加密，确保数据在传输过程中的安全性，防止中间人攻击和窃听。

加密方式：

HTTP不进行加密，数据以纯文本形式传输。
HTTPS使用SSL/TLS协议对数据进行加密，包括对传输的数据进行加密、身份验证和完整性保护。

端口：

HTTP默认使用端口80进行通信。
HTTPS默认使用端口443进行通信。

证书

HTTP不需要证书。
HTTPS需要服务器端使用SSL/TLS证书，用于验证服务器的身份，确保客户端连接到的是预期的服务器。

性能：

由于HTTPS需要进行加密和解密等额外的计算，相对于HTTP而言，会增加一些性能开销。
不过随着硬件和加密算法的改进，HTTPS在性能方面的影响已经大大减少。

总的来说，HTTPS相比于HTTP更安全可靠，适用于对数据安全性要求较高的场景，例如网上银行、电子商务等。而HTTP更适用于对数据安全性要求不高的场景，例如普通网页浏览、信息查询等。在公司内网内做开发，写的代码只对内网提供服务，大概率服务使用的是HTTP协议，如果哪天想让外网朋友也体验下我们的服务，那就需要在HTTP层上加一层TLS层，让http的明文变为密文，就成了我们说的HTTPS。

HTTPS握手过程

首先简历TCP连接，毕竟HTTP是基于TCP的应用层协议
在TCP成功建立后，开始进入HTTPS的加密流程。
整个加密分为两阶段。即TLS的四次握手和加密通信。
第一阶段TLS四次握手，利用非对称加密的特性交换信息，最后得到一个“会话密钥”。
第二阶段是在在第一阶段的“会话密钥”基础上，进行对称加密通信。
在这里插入图片描述

第一次握手：
Client Hello：首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。
（1）客户端支持的 TLS 协议版本，如 TLS 1.2 版本。
（2）客户端生产的随机数（Client Random），后面用于生成「会话秘钥」条件之一。
（3）客户端支持的密码套件列表，如 RSA 加密算法。
第二次握手：
Server Hello服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello。服务器回应的内容有如下内容：
（1）确认 TLS 协议版本，如果浏览器不支持，则关闭加密通信。
（2）服务器生产的随机数（Server Random），也是后面用于生产「会话秘钥」条件之一。
（3）确认的密码套件列表，如 RSA 加密算法。
（4）服务器的数字证书。
第三次握手：

Client Key Exchange: 此时客户端再生成一个随机数，叫 pre_master_key 。从第二次握手的服务器证书里取出服务器公钥，用公钥加密 pre_master_key，发给服务器。
Change Cipher Spec: 客户端这边已经拥有三个随机数：客户端随机数，服务器随机数和pre_master_key，用这三个随机数进行计算得到一个"会话秘钥"。此时客户端通知服务端，后面会用这个会话秘钥进行对称机密通信。
Encrypted Handshake Message：客户端会把迄今为止的通信数据内容生成一个摘要，用"会话秘钥"加密一下，发给服务器做校验，此时客户端这边的握手流程就结束了，因此也叫Finished报文。

第四次握手：

Change Cipher Spec：服务端此时拿到客户端传来的 pre_master_key（虽然被服务器公钥加密过，但服务器有私钥，能解密获得原文），集齐三个随机数，跟客户端一样，用这三个随机数通过同样的算法获得一个"会话秘钥"。此时服务器告诉客户端，后面会用这个"会话秘钥"进行加密通信。
Encrypted Handshake Message：跟客户端的操作一样，将迄今为止的通信数据内容生成一个摘要，用"会话秘钥"加密一下，发给客户端做校验，到这里，服务端的握手流程也结束了，因此这也叫Finished报文。

HTTPS到底是对称加密还是非对称机密？

是都采用了的，前期4次握手，本质上就是在利用非对称加密的特点，交换三个随机数。为了最后用这三个随机数生成对称加密的会话密钥。后期就一直用对称加密的方式进行通信。

为什么不都用非对称加密呢？

因为非对称加密慢，对称加密相对来说快一些。

第二次握手里的服务器证书是什么？怎么从里面取出公钥？

服务器证书，本质上是，被权威数字证书机构（CA）的私钥加密过的服务器公钥。

被私钥加密过的数据，是可以用公钥来解密的。而公钥是任何人都可以得到的。所以第二次握手的时候，客户端可以通过CA的公钥，来解密服务器证书，从而拿到藏在里面的服务器公钥。

为什么我不能只传公钥，而要拿CA的私钥加密一次再传过去？

反过来想想，如果只传公钥，公钥就有可能会在传输的过程中就被黑客替换掉。然后第三次握手时客户端会拿着假公钥来加密第三个随机数 pre_master_key，黑客解密后自然就知道了最为关键的 pre_master_key。又因为第一和第二个随机数是公开的，因此就可以计算出"会话秘钥"。
所以需要有个办法证明客户端拿到的公钥是真正的服务器公钥，于是就拿CA的私钥去做一次加密变成服务器证书，这样客户端拿CA的公钥去解密，就能验证是不是真正的服务器公钥。

怎么去获得CA的公钥？

最容易想到的是请求CA的官网，获取公钥。但全世界要上网的人那么多，都用去请求CA官网的话，官网肯定顶不住。
考虑到能颁发证书的CA机构可不多，因此对应的CA公钥也不多，把他们直接作为配置放到操作系统或者浏览器里，这就完美解决了上面的问题。

别人就拿不到你这三个随机数？

这三个随机数，两个来自客户端，一个来自服务端。第一次和第二次握手里的客户端随机数和服务端随机数，都是明文的。只要有心，大家都能拿到。
但第三个随机数 pre_master_key 则不行，因为它在客户端生成后，发给服务器之前，被服务器的公钥加密过，因此只有服务器本器才能用私钥进行解密。就算被别人拿到了，没有服务器的私钥，也无法解密出原文。