【Linux 28】应用层协议 - HTTPS

🌈 一、HTTPS 相关概念

⭐ 1. 什么是 HTTPS

• HTTPS 也是一个应用层协议，它在 HTTP 协议的基础上引入了一个加密层。
  HTTP 协议的内容由于都是按照文本的方式明文传输的，HTTP 无论是用 GET 还是 POST 进行传参，都没有任何加密，这就导致在传输过程中出现一些被篡改的情况。
• 为了解决 HTTP 在安全方面的问题，HTTPS 协议就这样诞生了。HTTPS 在应用层和传输层之间加了一层加密层 (加密层本身还是属于应用层)，加密层会对用户的个人信息进行加密 / 解密。
• HTTPS 在交付数据时，会先把数据交给加密层，由加密层对数据加密之后再交给传输层。
• 总结起来也就一句话：HTTPS 是经过了加密解密的 HTTP。

⭐ 2. 加密 & 解密 & 密钥

• 加密：将明文 (要传输的数据) 通过某种转换规则转换成密文的过程。
• 解密：将密文通过某种转换规则还原成明文的过程。
• 密钥：在加密和解密的过程中，需要 1 ~ n 个中间数据来辅助这个过程，这样的数据就被称之为密钥。

解释 加密 & 解密 & 密钥 的关系

• 使用凯撒密码为例，说明这三者之间的关系。

• 在这个例子中，“HELLO WORLD” 是明文，“KHOOR ZRUOG” 是密文，而密钥是 3。密钥在加密和解密过程中起着至关重要的作用，只有知道密钥的人才能将密文解密回原文。这也体现了加密技术的基本思想：通过密钥保护信息的机密性。

⭐ 3. 常见的加密方式

• 常见的加密方式分为对称加密和非对称加密。

1. 对称加密

• 采用单密钥系统的加密方式被称为对称加密，该加密方式的特征就是加密和解密所用的密钥相同。

  • 例：上文的凯撒密码就是对称加密，加密和解密用的都是 3 这个密钥。

• 常见的对称加密算法：DES、3DES、AES、TDEA、Blowfish、RC2 等。

• 对称加密的特点：算法公开、计算量小、加密解密速度快、效率高。

2. 非对称加密

• 采用双密钥系统的加密方式被称为非对称加密，这两个密钥分别是公开密钥 (public key) 和 私有密钥 (private key)。

  • 公开密钥顾名思义就是可以在网络上公开的密钥，而私有密钥则只有自己知道。

• 常见的非对称加密算法：RSA、DSA、ECDSA。

• 非对称加密的特点：算法强度复杂，加密 / 解密速度慢，安全性依赖于算法和密钥。

• 这两种密钥都可以用作加密和解密，且公钥和私钥是配对的，用一种密钥加密，则必须用另一种解密。

  1. 如果使用 公钥加密，私钥解密，则只有持有私钥的人才能解密。能加密的人多，能解密的人少。
  2. 如果使用 私钥加密，公钥解密，则持有公钥的人都能进行解密。能加密的人少，能解密的人多。

• 上述两种方法没有谁好谁坏之分，根据实际场景判断加密的人多，还是解密的人多进行选择即可。

⭐ 4. 数据摘要 & 数据指纹

• 数据摘要 (也叫数据指纹)，其通过单向散列函数对数据进行运算，生成一串固定长度的数字摘要。

  • 不管是一个字还是一万个字生成的数据摘要长度都一样，数据摘要的固定长度取决于所使用的算法。

• 由于生成数据摘要采用的是哈希的方式，因此生成数据摘要的过程不可逆 (可以用 key 知道 value，但不能通过 value 获取到 key)。

  • 由于数据摘要不能解密，因此它不是加密机制，主要用来判断数据是否被篡改。

• 常见数据摘要算法：MD5、SHA1、SHA256 等。

• 这些算法会将无限的映射成有限的，因此可能会发生哈希碰撞。

• 数据摘要的特征：因为摘要并不是加密机制，因此也没有解密的说法。

• 由于很难对数据摘要进行反推得出原信息，通常被用来进行数据对比。

1. 举个例子

2. 数据摘要的应用场景

• 在使用网盘客户端上传文件时，如果网盘服务端检测到你要上传的文件已经有了，就会触发秒传机制。
• 服务端通过数据摘要的方式来判断要上传的文件是否已经存在。由于数据摘要是唯一的，因此可以用它来当作索引的键值。
• 在要上传时，客户端会对要上传的文件生成一份数据摘要，然后将数据摘要发送给服务端，和服务端中已有的数据摘要进行对比。
• 如果找到了这个数据摘要，则说明要上传的文件已经在服务端有一份了，直接触发秒传，如果没找到就老老实实的上传。

⭐ 5. 初识数字签名

• 对数据摘要进行加密之后，就能得到数字签名。

举个例子

🌈 二、HTTPS 的加密方案探究

⭐ 1. 方案一：只使用对称加密

• 首先声明，该方案不具备任何可行性。

为何只使用对称加密的方案不具备可行性

• 当通信双方各自持有同一个密钥 X，且没别人知道时。可以保证这两方的通信安全（除非密钥被破解）。
• 引入对称加密后，即使数据被截获，由于黑客不知道密钥是啥，因此就无法进行解密，也就不知道请求的真实内容了。

• 这种方法虽然能防止明文请求被截取，但它也有自己的问题存在。
• 服务器同一时刻不可能只给一台客户端提供服务，在给多客户端提供服务时，每台客户端所使用的密钥都必须不同 (如果相同就容易扩散，黑客获取密钥成本大大降低)。因此服务器还需要维护每个客户端和每个密钥之间的关系，成本挠一下的就上来了。

• 如果想解决这个问题，可以在客户端和服务器建立连接的时候，双方协商确定这次的密钥。
• 但同时新的问题又诞生了，如果直接把密钥明文传输，黑客也就能获得密钥了。

• 因此，密钥的传输也要进行加密传输，但是要想对密钥进行对称加密，仍然需要先协商确定一个 “密钥的密钥”。
• 因此，如果只使用对称密钥进行加密，就会陷入上述问题的死循环中。

⭐ 2. 方案二：只使用非对称加密

• 首先声明，该方案存在安全性问题，不具备可行性。

为何只使用非对称加密的方案不具备可行性

• 由于非对称加密的机制，如果服务器先将公钥以明文的方式传输给客户端。
• 之后客户端再向服务器发送数据前，都先用这个公钥对数据进行加密后再进行密文传输。从客户端到服务器的通信信道似乎是安全的。
• 但无法保证服务器到客户端的通信信道的安全。如果服务器使用它的私钥对数据加密后传给客户端，那么浏览器就可以用服务器提供的公钥对该密文进行解密。由于服务器的公钥是公开的，如果这个公钥被中间人劫持了，就能用来解密从服务器传来的信息。

⭐ 3. 方案三：双方都使用非对称加密

• 首先声明，该方案存在安全性、效率低的问题，不具备可行性。

1. 该方案加密解密的方式

1. 客户端和服务端得形成各自的公钥和私钥。服务端持有公钥 S 与对应的私钥 s，客户端持有公钥 C 与对应的私钥 c
2. 客户端与服务端互换公钥
3. 客户端给服务端发数据：客户端先用服务端的公钥 S 对数据加密后发送，该密文只有持有私钥 s 的服务端能解。
4. 服务端给客户端发数据：服务端先用客户端的公钥 C 对数据加密后发送，该密文只有持有私钥 c 的客户端能解。

为何双方都使用非对称加密的方案不具备可行性

• 效率低：已经知道了非对称加密的特点之一就是效率低，这个方案用了两个非对称加密，双倍的慢。

⭐ 4. 方案四：非对称加密 + 对称加密

• 该方案的密钥协商过程采用非对称加密，在通信的过程采用对称加密。
• 该方案几乎接近正确答案，但由于还是无法解决安全问题，因此还是不可行。

1. 密钥协商过程采用非对称加密，能有效解决效率问题

1. 服务端生成自己的非对称密钥，其中 公钥 S 和 私钥 s
2. 客户端发起 HTTPS 请求，获取服务端的公钥 S
3. 客户端在本地生成对称密钥 C，通过服务端的公钥 S 对密钥 C 进行加密，然后将被加密的密钥 C 发送给服务器。
4. 由于中间的网络设备没有服务端的私钥 s，即使截获了数据，也无法还原出内部的原文，即无法获取到对称密钥 C
5. 服务器通过持有的私钥 s 解密，还原出客户端发送的对称密钥 C，并且使用这个对称密钥加密给客户端返回的响应数据。
6. 后续客户端和服务器的通信都只用对称加密即可。
   • 由于密钥 C 只有客户端和服务器两个主机知道，其他主机 / 设备不知道密钥即使截获数据也没有意义。

2. 无法解决安全问题 (详情见中间人攻击)

🌈 三、中间人攻击

• 数据在网络中并不是直接到达目的地，中间可能会经过多个中间设备 (如路由器) 进行中转，中间人就是劫持了中间设备的非法用户。
• 方案一 到 方案四 都不能解决安全问题，其中看着最行的 方案四 也会因为中间人攻击而导致出现安全问题。
  • 注：方案一 到 方案四 都会因为下面的中间人攻击而产生安全问题。

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

• 如果最开始服务端在传输公钥 S 的时候，中间人就将公钥换成了自己的公钥，安全问题这不就出来了，过程如下：

1. 服务端持有非对称密钥中的公钥 S，私钥 s。

2. 中间人持有非对称密钥中的公钥 M，私钥 m。

3. 客户端向服务器发起请求报文，服务器通过响应报文将公钥 S 明文传送给客户端。

4. 中间人劫持响应报文，提取公钥 S 并保存好，然后将被劫持报文中的公钥 S 替换成中间人的公钥 M，并将伪造报文发给客户端。

5. 客户端收到伪造的报文，提取公钥 M，在本地形成对称秘钥 C，用公钥 M 加密 C，形成请求报文发送给服务器。

6. 中间人劫持请求报文，用自己的私钥 m 进行解密，得到通信秘钥 C，再用曾经保存的服务端公钥 S 加密后，将报文推送给服务器。

7. 服务器拿到报文，用自己的私钥 s 解密，得到通信秘钥 C。

8. 双方开始采用密钥 C 进行对称加密，开始通信，完全不知道密钥 C 已经暴露给中间人了。

• 看起来没问题的方案四就这样被破解了，服务端和客户端之间的通信已经相当于在中间人面前裸奔了。
• 都走到这了，这 4 个方案都不可行，那么就只有方案五既能解决效率问题，又能解决安全问题了。

🌈 四、引入证书解决中间人攻击

• 想要解决中间人攻击的问题，就需要引入证书这个东西。
• 中间人攻击的问题处在客户端与服务端建立通信的最开始 (中间人劫持了服务端的公钥)，只要将这个漏洞补上即可解决中间人攻击的问题。
• 中间人攻击的核心问题在于客户端无法确定收到的含有公钥的数据报文，就是目标服务器发送过来的，只要把这个问题解决就行了。

⭐ 1. CA 证书

• 服务端在使用 HTTPS 前，需要向 CA 机构申请一份数字证书，数字证书里面包含证书申请者信息、公钥信息等。
• 服务端将这个数字证书发给客户端，客户端通过数字签名判断收到的这个数字证书是否是从目标服务器发来的。
• 如果客户端判断出数字证书是从目标服务器发来的，接下来客户端只需要从证书中获取公钥即可。
• 不管中间人怎么蹦跶，只要识别出接收到的数字证书的数字签名不对劲，客户端都不予理睬。

申请 CA 证书的基本流程

• 当申请完 CA 证书后，会将这个 CA 证书内置到自己的 HTTP 服务器中。
• 之后在与客户端正式进行通信前，先把证书发出去，证明自己的身份。

⭐ 2. 理解数字签名

• 数字签名在 HTTPS 中，用于辅助客户端判断接收到的数字证书是否是目标服务器发来的。
  • 注：签名的形成基于非对称加密算法，暂时和 HTTPS 没关系，不要和 HTTPS 中的公钥私钥搞混了。

数字证书的形成过程

• 当服务端申请 CA 证书时，CA 机构会审核该服务端，并专门为该网站形成数字签名，过程如下：

  1. CA 机构拥有非对称加密的公钥 A 和私钥 a

  2. CA 机构对服务端申请的证书明文数据进行 hash，形成数据摘要

  3. CA 机构对数据摘要使用私钥 a 进行加密，得到数字签名 S

• 服务端申请的证书明文和数字签名 S 共同组成了数字证书，这样一份数字证书就可以正式颁发给服务端了。

• 由于只能使用签名者 (HTTP 的签名者是 CA 机构) 的公钥对数字签名进行解密，只要发现收到的公钥和内置的签名者的公钥不一致，就不会进行之后的验证。

  • 服务端和客户端都内置了 CA 机构这个签名者的公钥。

⭐ 3. 方案五：非对称加密 + 对称加密 + 证书认证

• 方案五就是在方案四的基础上添加一个证书认证环节。
• 客户端和服务端一建立连接，服务端就立马给客户端返回一个数字证书，来证明自己的合法性。
  • 证书中内置了服务端的公钥、网站的身份信息等。

• 之后客户端在进行认证时，就会使用内置在客户端的签名者的公钥对数字签名进行解密，验证获取到的这个证书。

1. 客户端要验证证书的哪些内容

1. 验证证书的有效期是否过期。
2. 验证证书的发布机构是否可信 (客户端中都已经内置了所有可信的证书发布机构的公钥)。
3. 验证证书的内容是否被篡改：从系统中拿到该证书发布机构的公钥，对签名解密，得到一 个 hash 值 (数据摘要)，设为 hash1。然后计算整个证书的 hash 值, 设为 hash2。对比 hash1 和 hash2 是否相等。 如果相等，则说明证书是没有被篡改过的。

2. 查看浏览器中内置的可信的证书发布机构

• 以 edge 浏览器为例，在设置中搜索管理证书，然后点击第一个管理证书即可。

🌈 五、HTTPS 的工作流程

1. 客户端发起连接请求：客户端 (通常是浏览器) 向服务器发送一个安全连接请求。
2. 服务器向客户端发送证书：服务器收到客户端的连接请求后，将内置在 HTTPS 服务器内的数字证书作为响应报文返回给客户端。
3. 客户端验证收到的证书：浏览器在接收到服务端发送过来的数字证书后，会验证该证书的合法性 (判断这个证书是否是 CA 机构颁发的)。
4. 密钥协商：当服务端的数字证书通过客户端的验证过后，客户端会在本地生成一个对称密钥，用于后续的数据加密和解密。客户端会使用从数字证书中提取出来的服务端的公钥对这个对称密钥进行加密，然后发送给服务端。
5. 通信加密：服务端接收到使用服务端的公钥加密的对称密钥，服务端使用自己的私钥进行解密，获取客户端生成的对称密钥。至此，客户端与服务端之间就建立起了一个加密的安全通道，客户端和服务端之间的数据传输都会在这个安全通道中进行。
6. 安全数据传输：建立好安全通道后，客户端和服务端之间就可以安全的进行数据传输了。在发送数据前，发送端会使用持有的对称密钥对数据进行加密，然后接收端就会使用相同的对称密钥对数据进行解密。
7. 完整性检查：为了防止数据在传输过程中被篡改，HTTPS 还需要使用数据摘要对数据进行完整性检查。接收方会对接收到的数据进行校验，并判断校验结果是否与发送方所计算的结果相同。

完整的工作流程示意图

• 左侧都是客户端做的事，右侧都是服务器做的事。

🌈 六、HTTPS 总结

• 在 HTTPS 的工作过程中涉及到的密钥有三组。

1. 第一组：非对称加密

• 用于校验证书是否被篡改。
• 服务端持有私钥 (私钥在形成 CSR 文件与申请证书时获得)，客户端持有公钥 (客户端中内置了所有可信的 CA 认证机构，同时持有对应的公钥)。 服务端在客户端请求时，返回携带签名的证书。客户端通过这个公钥进行证书验证，保证证书的合法性，进一步保证证书中携带的服务端公钥权威性。

2. 第⼆组：非对称加密

• 用于协商生成对称加密的密钥。
• 客户端用收到的 CA 证书中的公钥 (是可被信任的) 给随机生成的对称加密的密钥加密，然后传输给服务端，服务端通过私钥解密获取到对称加密密钥。

3. 第三组：对称加密

• 用于对客户端和服务器后续传输的数据进行加密解密。
• HTTPS 一切工作的关键就是这个对称加密的密钥。 其他的机制都是辅助这个密钥工作的。第二组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器。第一组非对称加密的密钥是为了让客户端拿到第⼆组非对称加密的公钥。

书中携带的服务端公钥权威性。

2. 第⼆组：非对称加密

• 用于协商生成对称加密的密钥。
• 客户端用收到的 CA 证书中的公钥 (是可被信任的) 给随机生成的对称加密的密钥加密，然后传输给服务端，服务端通过私钥解密获取到对称加密密钥。

3. 第三组：对称加密

• 用于对客户端和服务器后续传输的数据进行加密解密。
• HTTPS 一切工作的关键就是这个对称加密的密钥。 其他的机制都是辅助这个密钥工作的。第二组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器。第一组非对称加密的密钥是为了让客户端拿到第⼆组非对称加密的公钥。