HTTPS 加密原理、数字指纹与 CA 认证详解

其实在网络通信，我们要解决的是如下问题：

1. 数据被监听
2. 数据被篡改

1 方案一：对称加密

如果通信双方都各自持有同一个密钥 X，且没有别人知道，这两方的通信安全当然是可以被保证的（除非密钥被破解）

服务器同一时刻其实是给很多客户端提供服务的。这么多客户端，每个人用的秘钥都必须是不同的 (如果是相同那密钥就太容易扩散了，黑客就也能拿到了)。因此服务器就需要维护每个客户端和每个密钥之间的关联关系，这也是个很麻烦的事情~

缺点：

上面还不是最重要的，最重要的是最开始的时候我们怎么保证客户端和服务器看到的是同一个密钥。

• 如果最开始客户端把密钥发给服务器，那这个密钥是明文传还是密文传？
• 明文传那黑客不就拿到了，
• 密文加密传那就需要对密钥进行加密，就仍然需要先协商确定一个'密钥的密钥'

这不就是鸡生蛋还是蛋生鸡的问题吗？所以纯纯使用对称加密是不行的！

2 方案二：非对称加密

通信之前先得交换密钥，鉴于非对称加密的机制，用公钥和私钥都可以加密，但用公钥加密就要使用私钥解密，使用私钥加密就要使用公钥解密，所以可以尝试如下图操作：

缺点：

现在只能保证从 C->S 的安全性 (暂时的安全)，没有办法解决 S->C 的安全性。 没事我们在提第三种方案。

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

1. 服务端拥有公钥 S 与对应的私钥 S'，客户端拥有公钥 C 与对应的私钥 C'
2. 客户和服务端互相交换公钥
3. 客户端给服务端发信息：先用 S 对数据加密，再发送，只能由服务器解密，因为只有服务器有私钥 S'
4. 服务端给客户端发信息：先用 C 对数据加密，在发送，只能由客户端解密，因为只有客户端有私钥 C'

缺点：

1. 慢
2. 还是有安全问题，这是和方案二安全问题是一样的，下面在提它们的安全问题

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

这种方案通过非对称加密进行密钥交换，之后的数据传输使用对称加密，从而兼顾了安全性和效率。具体流程如下：

1. 客户端发起 HTTPS 请求，获取服务器的公钥。
2. 客户端生成一个对称密钥，并使用服务器的公钥加密后发送给服务器。
3. 服务器通过私钥解密，获得对称密钥。
4. 随后的通信使用对称加密进行数据传输。

前半部分采用非对称加密：交换密钥，后半部分采用对称加密：双方不存在了安全问题。既安全，又高效。

但真的没有问题了吗？

方案二、方案三、方案四都存在一个问题，如果最开始，中间人就已经开始攻击了呢？

5 中间人攻击

中间人攻击是指在客户端与服务器通信的过程中，攻击者通过劫持并篡改数据进行窃听或伪造。

在方案 2/3/4 中，客户端获取到公钥 S 之后，客户端形成的对称秘钥 C，然后用服务端给客户端的公钥 S 对 C 进加密，中间人即使窃取到了数据，此时中间人确实无法解出客户端形成的密钥 C，因为只有服务器有私钥 S'。

但是中间人的攻击，如果在最开始握手协商的时候就进行了，那就不一定了，如果 M 在请求公钥后就已经成功成为了中间人

• 客户端向服务器发起请求，服务器明文传送公钥 S 给客户端
• 中间人劫持数据报文，提取公钥 S 并保存好，然后将被劫持报文中的公钥 S 替换成为自己的公钥 M，并将伪造报文发给客户端

上面的攻击方案，同样适用于方案 2、方案 3

问题本质出在哪里了呢？ 服务器返回公钥的时候，被中间人窃取并替换了&&客户端没有辨别公钥是否合法的能力

下面要围绕**客户端能够具有辨别服务器发过来的公钥的合法性！**来解决问题，避免公钥被替换

为了防止这种攻击，HTTPS 引入了证书认证机制。

三。非对称 + 对称+CA 认证

1. CA 认证与证书

为了防止中间人篡改公钥，HTTPS 采用了数字证书认证机制。CA（Certificate Authority）作为权威的第三方机构，为服务器颁发数字证书，保证公钥的真实性。证书的验证流程如下：

1. 服务器向 CA 机构申请证书，CA 机构对服务器的公钥进行签名并颁发证书。
2. 客户端在建立 HTTPS 连接时，会首先获取服务器的证书，并验证证书是否由可信的 CA 签发、是否过期、是否被篡改。
3. 只有在证书验证通过后，客户端才会信任服务器，并使用其公钥进行加密通信。

证书可以理解成是一个结构化的字符串，里面包含了以下信息：证书发布机构、证书有效期、公钥、证书所有者、签名等等

客户端能够具有辨别服务器发过来的公钥的合法性! 我们说是通过证书来进行甄别的，那证书如何做到的呢？

原理：

签名：

• 对一份文本 (可以认为这里是 CA 证书内的明文信息) 经过 hash 散列形成散列值，我们称之为数据摘要。然后用签名者的私钥 (CA 机构的私钥) 对数据摘要加密形成了数据签名
• 更重要的把这个数据签名和这个明文信息合在一起，形成数字签名的数据。

验证：

• 把原始文本和签名分开，一个对原始文本使用相同的散列函数进行散列形成散列值，另一个对签名用签名者的公钥解密形成散列值
• 然后对比两个散列值，如果这两个散列值不一样，就注定有人要么改了原始文件，要么改了签名。
• 只要这两个散列值一样，那么原始文本和它曾经形成的签名是一样的，说明这个原始文本没有被篡改过！

通过验证可以确保：数据和签名的证书不被更改啦

首先说一下，CA 为了签发证书，CA 也有自己的 CA 公钥，CA 私钥。

因为我们使用 CA 的私钥形成数据签名，所以只有 CA 能形成可信任的证书！(CA 私钥只在 CA)

实际验证场景：

• 将证书上的明文数据和数字签名分开，把明文数据经过相同的 hash 映射 (这个 hash 是公开的) 形成数据摘要。因为 CA 会在所有的浏览器中内置自己的公钥！
• 所以浏览器会拿着 CA 公钥对 CA 曾经的数字签名进行解密！得到曾经原始数据的摘要。然后对比两个摘要。两者相等说明证书内部没被串改，如果两者不相等说明证书被篡改过。

⭕中间人有没有可能篡改该证书？

• 明文篡改：
  • 中间人可以尝试篡改证书的明文部分。
  • 但是，由于中间人不具备证书颁发机构（CA）的私钥，因此无法生成与篡改后的证书相匹配的有效数字签名。
• 验证失败：
  • 如果证书被篡改，客户端会使用其存储的信任链中的 CA 公钥来验证证书签名。
  • 客户端将计算证书明文的哈希值，并用 CA 的公钥解密签名。
  • 如果哈希值不匹配，则表明证书已被篡改，客户端会认为证书不可信并中断连接。
• 私钥加密：
  • 中间人不能使用自己的私钥来替换或重新加密证书，因为客户端会使用特定 CA 的公钥来验证签名。
  • 客户端将无法正确解密签名，从而检测到篡改。

⭕中间人整个掉包证书？

• 证书掉包：

  • 即使中间人试图用自己的合法证书来完全替换原始证书，这也会导致问题。
  • 证书包含了诸如域名等标识信息，这些信息必须与客户端正在访问的服务匹配。

• 如果证书中的域名与实际服务不符，客户端同样会拒绝接受该证书。

结论：

• 中间人缺乏必要的 CA 私钥，无法对任何证书进行合法修改。
• 证书包含的信息以及数字签名机制确保了即使中间人尝试篡改或替换证书，客户端也能检测出异常并采取安全措施，如中断连接以防止潜在的信息泄露。

常见问题：

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

• MD5 特性：
  • **定长：**不论输入字符串的长度如何，生成的 MD5 值都是固定长度（16 字节或 32 字节）。
  • **分散：**输入字符串的任何微小变化都会导致输出的 MD5 值显著不同。
  • **不可逆：**从原始字符串生成 MD5 值容易，但从 MD5 值反推回原始字符串在理论上是不可能的。

由于这些特性，如果两个字符串具有相同的 MD5 值，则可以认为这两个字符串是相同的。这使得 MD5 可以用来验证数据完整性。

理解证书篡改的判定过程：

• 假设有一个简单的字符串 "hello" 作为证书内容，其 MD5 值为 BC4B2A76B9719D91。
• 如果 "hello" 被篡改为 "hella"，则新的 MD5 值将完全不同，例如 BDBD6F9CF51F2FD8。
• 当服务器发送 "hello" 和其对应的 MD5 值给客户端时，客户端可以通过重新计算 "hello" 的 MD5 来验证是否被篡改。

存在的问题：

• 如果攻击者篡改了 "hello" 并且同时更新了相应的 MD5 值，那么客户端就无法检测到这种篡改。

解决方案：

• 对证书明文进行哈希处理后，使用 CA 的私钥对哈希值进行加密形成签名。
• 将明文 + 加密后的签名一起组成完整的 CA 证书，并发送给服务端。
• 客户端接收证书后，利用操作系统中预存的 CA 公钥解密签名，还原出原始哈希值，并与自己计算的哈希值对比，以此来验证证书的合法性。

为什么签名不直接加密，而是要先 hash 形成摘要？

• 减少需要加密的数据量，从而加快数字签名的生成和验证速度。

如何成为中间人？

• **ARP 欺骗：**在局域网内，攻击者通过监听 ARP 请求广播包获取其他节点的 IP 和 MAC 地址信息，然后向受害者发送伪造的 ARP 应答，声称自己是另一台主机，从而使受害者的流量被重定向到攻击者处。
• ICMP 重定向攻击：利用 ICMP 协议中的重定向报文类型，攻击者可以伪造一个 ICMP 重定向消息，使目标设备误以为攻击者提供了一个更优的路由路径，进而所有流量都被导向攻击者指定的位置。
• **假 WiFi 和假网站：**攻击者设置虚假的无线网络接入点或模仿合法网站的界面，诱使用户连接并泄露敏感信息。

2. HTTPS 的完整工作流程

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

HTTPS 的完整工作流程涉及三组密钥：

1. 第一组密钥（非对称加密）：用于验证证书的合法性。客户端通过 CA 的公钥验证服务器证书是否被篡改。
2. 第二组密钥（非对称加密）：用于加密传输对称密钥。客户端使用服务器的公钥加密对称密钥，服务器通过私钥解密。
3. 第三组密钥（对称加密）：用于后续数据传输的加密解密操作。

这个流程确保了客户端与服务器之间的通信安全，避免数据在传输过程中被窃取或篡改。

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

• 第⼆组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器。
• （CA 认证中进行）第一组非对称加密的密钥是为了让客户端拿到第⼆组非对称加密的公钥。