http安全加密

https://blog.youkuaiyun.com/2301_80224556/article/details/141384753

预备知识

2.1 HTTPS是什么

https(全称：Hypertext Transfer Protocol Secure)，是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性，是 HTTP 的安全版本。

1. HTTPS 经由 HTTP 进行通信，但是在 HTTP 的基础上引入了一个加密层，使用 SSL/TLS 来加密数据包。
2. HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。
3. HTTPS 默认工作在 TCP 协议443端口(HTTP默认80端口)

既然要保证数据安全，就需要进行“加密”，即网络传输中不再直接传输明文，而是加密之后的“密文”。

为了更好的加密，就在应用层和传输层之间加了一个安全层，使用 SSL/TLS 来加密数据包。

也就是说，
Https是身披SSL/TLS外壳的HTTP协议，它并非一个新的协议而是在HTTP的基础上新增了安全层(SSL/TLS),HTTPS先和安全层通信，然后安全层和TCP层通信。

2.2 加密和解密

• 加密：把明文经过一系列变换，形成密文
• 解密：把密文经过一系列变换，还原成明文

在加密与解密的过程中需要一个或者多个辅助数据，我们将其称为 「密钥」, 无论加密或者解密都是需要密钥的。

加密示例：假设我们要加密的消息（明文）是 “HELLO”，并且我们选择的密钥是3（意味着字母表中的每个字母向后移动3位）。
H -> K (因为H向后移3位是K)
E -> H (E向后移3位是H)
L -> O (L向后移3位是O，注意这里超过了Z则循环回A)
L -> O (同上)
O -> R (O向后移3位是R）

解密示例：现在，如果我们收到密文 “KHOOR” 并知道密钥是3，我们可以通过相反的操作来解密，即将每个字母向前移3位来还原明文。
K -> H (K向前移3位是H)
H -> E (H向前移3位是E)
O -> L (O向前移3位是L)
O -> L (同上)
R -> O (R向前移3位是O)

2.3 常用加密方式

2.3.1 对称加密

采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密。

1. 特征:加密和解密所用的密钥是相同的
2. 常见对称加密算法(了解):DES、3DES、AES、TDEA、Blowfish、RC2等
3. 特点:算法公开、计算量小、加密速度快、加密效率高对称加密其实就是通过同一个"密钥",把明文加密成密文,并且也能把密文解密成明文.

一个简单的对称加密,按位异或
假设 明文a=1234,密钥 key=8888
则加密 a^key 得到的密文 b为 9834，然后针对密文 9834 再次进行运算 b^key，得到的就是原来的明文 1234

2.3.2 非对称加密

需要两个密钥来进行加密和解密，这两个密钥是公开密钥和私有密钥。

1. 常见非对称加密算法(了解):RSA，DSA，ECDSA
2. 特点:算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快。
3. 也可以反着用

2.3.3 单向加密

例如使用MD5校验码

---

3 HTTPS工作过程探究

3.1 方案选定

3.1.1 只使用对加密

适用场景：通信双⽅各⾃持有同⼀个密钥X，通信前能协商好密钥。算法固定且简单，适合定点传输。
问题：如果服务器服务于海量客户端，通信开始时才能协商并传输密钥，有可能在中间被截获密钥。因此密钥的传输也要加密。这就成了先有鸡还是先有 蛋"的问题了。

3.1.2 只使用非对称加密

含义为：

• 如果服务器先把公钥以明⽂⽅式传输给浏览器，之后浏览器向服务器传数据前都先⽤这个公钥加密好再传，从客户端到服务器信道似乎是安全的(有安全问题)，因为只有服务器有相应的私钥能解开公钥加密的数据。
• 但是服务器到浏览器的这条路怎么保障安全？
  如果服务器⽤它的私钥来对数据进行加密，然后传给浏览器，那么浏览器⽤公钥可以解密它，⽽这个公钥是⼀开始通过明⽂传输给浏览器的，若这个公钥被中间⼈劫持到了，那他也能⽤该公钥解密服务器传来的信息了。

适用场景：通信前能协商好公钥和密钥，适合定点传输
问题：定点传输时没有对称加密的算法简单；服务端到客户端的这条链路无法保证安全性

3.1.3 双方均使用非对称加密

我们看了方案2，会不会想到，让服务器和浏览器双方各持有自己的密钥和公钥。

1. 服务端拥有公钥A1与对应的私钥A11，客户端拥有公钥B1与对应的私钥B11
2. 服务器先把公钥A1以明⽂⽅式传输给浏览器，浏览器将公钥B1传递给服务器
3. 客户端给服务端发信息：先⽤A1对数据加密，再发送，只能由服务器解密，因为只有服务器有私钥 A11
4. 服务端给客户端发信息：先⽤B1对数据加密，再发送，只能由客户端解密，因为只有客户端有私钥 B11
   这样貌似也行啊，但是非对称加密效率太低 依旧有安全问题。

3.1.4 对称加密和非对称加密

服务端具有非对称公钥S1和私钥S11
客户端发起https请求，获取服务端公钥S1
服务端以明文方式发送公钥S1给客户端
客户端在本地生成对称密钥C，通过公钥S1加密，发送给服务器.
由于中间的网络设备没有私钥，即使截获了数据，也无法还原出内部的原文,也就无法获取到对称密钥(真的吗?)
服务器通过私钥S11解密，还原出客户端发送的对称密钥C，并且使用这个对称密钥C加密给客户端返回的响应数据.
后续客户端和服务器的通信都只用对称加密即可。由于该密钥只有客户端和服务器两个主机知道,其他主机/设备不知道密钥即使截获数据也没有意义.

种解决方案首先使用非对称式加密保证了 密钥传输时的安全性，确保只有客户端和服务器拥有 密钥，因为 密钥 加密与解密的特点就是 效率高，所以后续在传输数据时，整体效率就会高很多

由于对称加密的效率⽐⾮对称加密⾼很多,因此只是在开始阶段协商密钥的时候使⽤⾮对称加密,后 续的传输仍然使⽤对称加密. 虽然上⾯已经⽐较接近答案了，但是依旧有安全问题 。

---

3.2 加密算法的缺陷

客户端⽆法确定收到的含有公钥的数据报⽂，就是目标服务器发送过来的！

中间人攻击：

1. 服务器具有非对称加密算法的公钥S，私钥S’
2. 中间人具有非对称加密算法的公钥M，私钥M’
3. 客户端向服务器发起请求，服务器明文传送公钥S给客户端
4. 中间人劫持数据报文，提取公钥S并保存好，然后将被劫持报文中的公钥S替换成为自己的公钥M，并将伪造报文发给客户端
5. 客户端收到报文，提取公钥M，自己形成对称密钥X，用公钥M加密X，形成报文发送给服务器
6. 中间人劫持后，直接用自己私钥M’进行解密，得到通信秘钥X，再用曾经保存的服务端公钥S加密后，将报文推送给服务器
7. 服务器拿到报文，用自己的私钥S’解密，得到通信秘钥X
8. 双方开始采用X进行对称加密，进行通信。但是一切都在中间人的掌握中，劫持数据，进行窃听甚至修改，都是可以的

被攻击的核心原因：客户端无法验证公钥的合法性，此时就需要一个公平公正的第三方机构来进行认证，确保客户端所连接的服务器是合法的。

---

3.3 引入证书

3.3.1 数字摘要

数字摘要 又称为 数字指纹，指通过哈希函数对信息进行运算后生成的一串定长字符串，具有很强的唯一性，数字摘要 并不能加密，而是用于快速判断原始内容是否被修改。

⭐数字指纹(数据摘要),其基本原理是利用单向散列函数(Hash函数)对信息进行运算生成一串固定长度的数字摘要。数字指纹并不是一种加密机制，但可以用来判断数据有没有被窜改。
⭐摘要常见算法:有MD5、SHA1、 SHA256、SHA512等， 算法把无限的映射成有限，因此可能会有碰撞(两个不同的信息，算出的摘要相同，但是概率非常低)
⭐摘要特征:和加密算法的区别是，摘要严格意义不是加密,因为没有解密,只不过从摘要很难反推原信息，通常用来进行数据对比。

3.3.2数字签名

数字签名 是指将 数字摘要 通过加密后得到的字符串，计算过程需要借助 密钥
数字签名的验证过程如下：

• 发送方使用哈希函数对消息A进行摘要处理，生成消息摘要A1。
• 发送方使用密钥对消息摘要A1进行加密，生成数字签名A2。
• 发送方将消息A和数字签名A2一起发送给接收方。
• 接收方使用发送方的公钥对数字签名A2进行解密，得到消息摘要B1
• 接收方使用哈希函数对收到的消息A进行摘要处理，得到消息摘要B2。
• 接收方比对解密得到的消息摘要和计算得到的消息摘要，如果一致，则证明消息的完整性和真实性得到了保证。

3.3.3 CA证书

CA证书也就我们常说的数字证书，包含证书拥有者的身份信息，CA机构的签名，公钥和私钥。身份信息用于证明证书持有者的身份；CA签名用于保证身份的真实性；公钥和私钥用于通信过程中加解密，从而保证通讯信息的安全性
通常包含了

• 服务器的非对称密钥中的公钥；
• 持有者信息；
• 证书认证机构（CA）的信息；
• CA 对这份文件的数字签名及使用的算法；
• 证书有效期；
• 还有一些其他额外信息；

4.CA证书数字签名的验证过程：

1. CA证书的签发：当客户端向服务器发起请求时，服务器会发送它的数字证书。这份证书中包含了服务器用于加密的公钥和其他信息。服务器在向CA机构申请生成CA证书时，CA机构会对证书中的数据进行哈希运算得到数字摘要，最后使用CA的私钥对这个哈希值进行加密，生成数字签名。服务器将申请到的这个数字签名和证书一起发送给客户端。
2. CA证书的验证：当客户端收到服务器发送的证书后，它会使用浏览器内置的CA公钥来解密证书中的数字签名。如果解密成功，并且解密后的哈希值与客户端自己计算的哈希值一致，那么客户端就可以确认这个证书确实是由受信任的CA签发的，且在传输过程中没有被篡改。

---

3.3 最完善的方案

以下是最完善的方案，但很多场景并不需要这么复杂的方案。
「非对称式加密」+「对称式加密」+「CA证书」

1. 客户端发起请求：客户端向服务器发送HTTPS请求，要求建立安全连接。
2. 服务器响应并发送证书：服务器收到请求后，会发送自己的数字证书（包含服务器自己生成的非对称密钥中的公钥、数字签名以及其他的信息）给客户端。这个证书由可信的证书颁发机构（CA）签名。
3. 验证证书：客户端收到证书后，会使用内置的CA公钥来验证服务器证书的真实性。如果证书有效且可信，客户端会继续，否则会中断连接并向用户发出警告。
4. 生成对称加密密钥：客户端验证证书成功后，会生成一个随机的对称加密密钥，并使用服务器的公钥对客户端自己生成的密钥进行加密。
5. 发送加密的对称加密密钥：客户端将加密后的对称加密密钥发送给服务器。
6. 服务器解密对称加密密钥：服务器使用自己的私钥解密收到的对称加密密钥，从而获得客户端生成的对称加密密钥。
7. 建立安全通信：从此刻起，客户端和服务器都使用这个对称加密密钥进行通信。这种对称加密方式可以保证数据传输的保密性和完整性，因为对称加密在速度和效率上优于非对称加密。