【Linux】HTTPS

一、HTTPS 概念

         1 .什么是HTTPS

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

         2 .加密 & 解密 & 密钥

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

         3 . 常见的加密方式

非对称加密：

• 需要两个密钥来进行加密和解密，这两个密钥是公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）
• 常见非对称加密算法(了解)：RSA，DSA，ECDSA
  • 特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，而使得加
• 密解密速度没有对称加密解密的速度快。
• 非对称加密要用到两个密钥, 一个叫做 "公钥", 一个叫做 "私钥".
• 公钥和私钥是配对的. 最大的缺点就是运算速度非常慢，比对称加密要慢很多.
  • 通过公钥对明文加密, 变成密文
  • 通过私钥对密文解密, 变成明文
• 也可以反着用
  • 通过私钥对明文加密, 变成密文
  • 通过公钥对密文解密, 变成明文

栗子：

A 要给 B 一些重要的文件 , 但是 B 可能不在 . 于是 A 和 B 提前做出约定 :

B 说 : 我桌子上有个盒子 , 然后我给你一把锁 , 你把文件放盒子里用锁锁上 , 然后我回

头拿着钥匙来开锁取文件

在这个场景中 , 这把锁就相当于公钥 , 钥匙就是私钥 . 公钥给谁都行 ( 不怕泄露 ), 但是

私钥只有 B 自己持有 . 持有私钥的人才能解密 .

         4 . 数据摘要 & 数据指纹

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

         5 .数字签名

• HTTPS的数字签名是确保数据完整性和身份认证的关键技术。在HTTPS握手过程中，数字签名用于验证服务器的数字证书，确保证书的真实性和有效性

数字签名的原理

1. 生成数字摘要：首先，对要发送的数据使用哈希函数（如SHA-256）生成一个固定长度的数字摘要。这个摘要是对数据内容的唯一表示，任何对数据的修改都会导致摘要的变化。
2. 加密摘要：然后，使用发送方的私钥对数字摘要进行加密，形成数字签名。这个签名就像发送方的“电子签名”，只有发送方才能生成。
3. 发送原文和签名：发送方将原文和数字签名一起发送给接收方。
4. 验证签名：接收方收到原文和数字签名后，首先使用发送方的公钥对数字签名进行解密，得到数字摘要A。然后，它会对收到的原文使用相同的哈希函数生成数字摘要B。最后，将数字摘要A和数字摘要B进行对比。如果两者一致，说明原文在传输过程中没有被篡改，且发送方的身份得到了验证

HTTPS中的数字签名应用

• 证书验证：在HTTPS握手过程中，服务器会将其数字证书发送给客户端。客户端会验证证书中的数字签名，以确认服务器的身份和证书的完整性。证书由可信的证书颁发机构（CA）签发，CA使用其私钥对证书进行签名。
• 防止篡改：数字签名确保了在证书传输过程中，证书内容不被篡改。如果证书被篡改，其数字签名将不再有效，客户端在验证时会发现不一致。

通过数字签名，HTTPS能够有效地防止中间人攻击，确保客户端与服务器之间的通信安全

二、HTTPS 的加密方案探究

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

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

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

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

• 比较理想的做法, 就是能在客户端和服务器建⽴连接的时候, 双方协商确定这次的密钥是啥~

• 但是如果直接把密钥明文传输, 那么黑客也就能获得密钥了~~ 此时后续的加密操作就形同虚设了.

• 但是要想对密钥进行对称加密, 就仍然需要先协商确定一个 "密钥的密钥". 这就成了 "先有鸡还是先有蛋" 的问题了. 此时密钥的传输再用对称加密就行不通了.

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

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

• 由于非对称加密的机制，如果服务器先把公钥以明文方式传输给浏览器。
• 之后浏览器向服务器传数据前都先用这个公钥加密好再传，从客户端到服务器信道似乎是安全的
• 因为只有服务器有相应的私钥能解开公钥加密的数据。
• (安全问题)无法保证服务器到客户端的通信信道的安全。

问题：服务器到浏览器的这条路怎么保障安全？

• 如果服务器用它的私钥加密数据传给浏览器，那么浏览器用公钥可以解密它。
• 而这个公钥是一开始通过明文传输给浏览器的，若这个公钥被中间人劫持到了，那他也能用该公钥解密服务器传来的信息了。

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

• 问题：效率低，不安全，不具备可行性

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

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

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

• 效率低：非对称加密的特点之一就是效率低，若这个方案用了两个非对称加密的话，更慢了。
• 安全问题：如果中间人也生成两套公钥和私钥。在客户端和服务器连接的时候就进行劫持，之后发给双方中间人自己的公钥，发送数据的时候用劫持的公钥。这样就出现了安全问题。

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

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

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

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

• 方案 2，方案 3，方案 4 都存在一个问题，如果最开始，中间人就已经开始攻击了呢？

三、中间人攻击

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

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

• 中间人的攻击，如果在最开始握手协商的时候就进行了，那就不一定了，安全问题就出来了，过程如下：

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. 双方开始采用 X 进行对称加密，进行通信。 但是一切都在中间人的掌握中，劫持
   数据，进行窃听甚至修改，都是可以的

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

四、引入证书

• 中间人攻击的核心问题在于客户端无法确定收到的含有公钥的数据报文，就是目标服务器发送过来的，只要把这个问题解决就行了。

         1 .CA 证书

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

申请 CA 证书的基本流程

• 这个 证书 可以理解成是一个结构化的字符串, 里面包含了以下信息:

证书发布机构

证书有效期

公钥

证书所有者

签名

......

• 需要注意的是：申请证书的时候，需要在特定平台生成查，会同时生成一对⼉密钥对⼉，即公钥和私钥。这对密钥对⼉就是用来在网络通信中进行明文加密以及数字签名的。
• 其中公钥会随着 CSR 文件，一起发给 CA 进行权威认证，私钥服务端自己保留，用来后续进行通信（其实主要就是用来交换对称秘钥）
• 当申请完 CA 证书后，会将这个 CA 证书内置到自己的 HTTP 服务器中。
• 之后在与客户端正式进行通信前，先把证书发出去，证明自己的身份。

         2 .理解数字签名

• 签名的形成是基于非对称加密算法的。
• 注意，⽬前暂时和 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浏览器为例：

问题：中间人有没有可能篡改该证书？

• 如果中间人篡改了证书的明文
• 由于他没有 CA 机构的私钥，所以无法 hash 之后用私钥加密形成签名，那么也就没法办法对篡改后的证书形成匹配的签名
• 如果强行篡改，客户端收到该证书后会发现明文和签名解密后的值不一致，则说 明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人

问题： 中间人有没有可能整个掉包证书？

         4 . 常见问题

问题：为什么摘要内容在网络传输的时候一定要加密形成签名?

• 常见的摘要算法有: MD5 和 SHA 系列
• 以 MD5 为例, 我们不需要研究具体的计算签名的过程, 只需要了解 MD5 的特点:
  • 定⻓: 无论多⻓的字符串, 计算出来的 MD5 值都是固定⻓度 (16 字节版本或者32 字节版本)
  • 分散: 源字符串只要改变一点点, 最终得到的 MD5 值都会差别很大.
  • 不可逆: 通过源字符串生成 MD5 很容易, 但是通过 MD5 还原成原串理论上是不可能的.
• 正因为 MD5 有这样的特性, 我们可以认为如果两个字符串的 MD5 值相同, 则认为这两个字符串相同.

• 假设我们的证书只是一个简单的字符串 hello, 对这个字符串计算 hash 值(比如 md5),结果为 BC4B2A76B9719D91
• 如果 hello 中有任意的字符被篡改了, 比如变成了 hella, 那么计算的 md5 值就会变化很大. BDBD6F9CF51F2FD8
• 然后我们可以把这个字符串 hello 和 哈希值 BC4B2A76B9719D91 从服务器返回给客户端,
• 此时客户端如何验证 hello 是否是被篡改过?
• 那么就只要计算 hello 的哈希值, 看看是不是 BC4B2A76B9719D91 即可.

• 但是还有个问题, 如果黑客把 hello 篡改了, 同时也把哈希值重新计算下, 客户端就分辨不出来了呀.

• 所以被传输的哈希值不能传输明文, 需要传输密文.
• 所以，对证书明文(这里就是“hello”)hash 形成散列摘要，然后 CA 使用自己的私钥加密形成签名，将 hello 和加密的签名合起来形成 CA 证书，颁发给服务端，当客户端请求的时候，就发送给客户端，中间人截获了，因为没有 CA 私钥，就无法更改或者整体掉包，就能安全的证明，证书的合法性。
• 最后，客户端通过操作系统里已经存的了的证书发布机构的公钥进行解密, 还原出原始的哈希值, 再进行校验.

问题：为什么签名不直接加密，而是要先 hash 形成摘要 ?

• 缩⼩签名密文的⻓度,加快数字签名的验证签名的运算速度

         5 .如何成为中间人

• ARP 欺骗：在局域网中，hacker 经过收到 ARP Request⼴播包，能够偷听到其它节点的 (IP, MAC)地址。例， 黑客收到两个主机 A, B 的地址，告诉 B (受害者) ，自己是 A，使得 B 在发送给 A 的数据包都被黑客截取
• ICMP 攻击：由于 ICMP 协议中有重定向的报文类型，那么我们就可以伪造一个ICMP 信息然后发送给局域网中的客户端，并伪装自己是一个更好的路由通路。从而导致⽬标所有的上网流量都会发送到我们指定的接⼝上，达到和 ARP 欺骗同样的效果
• 假 wifi && 假网站等

五、HTTPS 的工作流程

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

完整的工作流程示意图

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

六、HTTPS 总结

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

         1 .第一组：非对称加密

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

         2 .第⼆组：非对称加密

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

         3 . 第三组：对称加密

• 用于对客户端和服务器后续传输的数据进行加密解密。

其实一切的关键都是围绕这个对称加密的密钥 . 其他的机制都是辅助这个密钥工作的 .

• 第⼆组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器.
• 第一组非对称加密的密钥是为了让客户端拿到第⼆组非对称加密的公钥