Linux笔记---HTTPS的原理

1. 什么是HTTPS

1.1 HTTPS简单介绍

HTTPS（Hypertext Transfer Protocol Secure，超文本传输安全协议）是 HTTP 的安全增强版本，核心目标是通过加密技术保护客户端（如浏览器）与服务器之间的数据传输安全，防止数据被窃听、篡改或伪造。它已成为现代互联网的基础安全标准，广泛应用于电商、网银、社交、支付等涉及敏感信息的场景。

HTTPS 并非独立协议，而是在 HTTP 协议之上增加了一层 TLS/SSL 加密层（TLS 是 SSL 的升级版，目前主流是 TLS 1.2 和 TLS 1.3），即：

HTTPS = HTTP + TLS/SSL 加密 + 身份认证 + 数据完整性校验

• TLS/SSL（Transport Layer Security/Secure Sockets Layer）是位于 TCP/IP 协议栈中 “传输层” 与 “应用层”（属于应用层） 之间的安全协议，负责实现三大核心功能：
  1. 数据加密：确保传输的数据只有收发双方能解密；
  2. 身份认证：验证服务器（可选验证客户端）的真实身份，防止 “中间人攻击”；
  3. 数据完整性：确保数据在传输过程中未被篡改（如插入恶意代码、修改内容）。

1.2 加密与解密

• 明文（Plaintext）：未加密的原始信息，是人可直接阅读、机器可直接处理的内容。
• 密文（Ciphertext）：明文经过 “加密算法” 处理后生成的 “乱码”，在未解密的情况下无法直接理解其含义。
• 密钥（Key）：控制加密 / 解密过程的 “关键参数”—— 加密时需要密钥将明文转密文，解密时必须用对应密钥才能恢复明文。没有正确密钥，即使拿到密文也无法破解。
• 加密：明文 + 密钥 + 加密算法 = 密文
• 解密：密文 + 密钥 + 解密算法 = 明文。

1.3 为什么要加密

在网络安全领域，中间人（Man-in-the-Middle，简称 MitM） 并非指日常场景中 “传递信息的中间角色”（如合法路由器、服务器），而是特指通过非法手段拦截、篡改、伪造通信数据，暗中插入到 “发送方” 与 “接收方” 之间的恶意角色 / 攻击行为（即 “中间人攻击”）。

其核心目的是窃取敏感信息、操纵通信内容，且让通信双方误以为自己在 “直接正常通信”，完全察觉不到中间人的存在。

例如一个很常见的现象：“运营商劫持”。

“运营商劫持” 是指网络运营商（如基础电信运营商、宽带服务商等）在未经用户或内容提供商允许的情况下，通过技术手段干预用户的网络流量传输过程，对数据内容进行篡改、拦截、重定向或附加额外信息的行为。

其本质是运营商利用自身控制的网络节点（如网关、DNS 服务器等），违背流量传输的 “中立性”，为自身或合作方谋取利益（如广告收益、强制推广等），同时可能损害用户权益或内容提供商的合法利益。

就比如有时候我们在浏览器当中下载应用时，常常在点击下载之后跳出来的下载任务框中显示的是另一款软件。最臭名昭著的就是应用宝和QQ浏览器。

这就是因为我们明文传输的下载请求被劫持，服务端传回来的下载链接被篡改，导致我们下载了错误的软件。

1.4 加密解密的主要类型

1.4.1 对称加密（Symmetric Encryption）

加密和解密使用同一把密钥（称为 “对称密钥”）—— 只要拿到这把密钥，既能加密，也能解密。

• 优点：算法简单、运算速度极快，适合加密 “大量数据”（如文件、视频、实时聊天内容）。
• 缺点：密钥传输存在风险 —— 若要给对方发送加密信息，必须先把 “对称密钥” 传给对方，但传输密钥的过程中，密钥可能被黑客拦截（比如你通过微信把密钥发给朋友，中途被窃取）。
• 常见算法与应用：
  • AES 算法（最主流）：用于加密手机文件、WiFi 数据传输、硬盘加密（如 BitLocker）；
  • DES 算法（较老旧，已逐渐淘汰）：早期用于银行数据加密。

1.4.2 非对称加密（Asymmetric Encryption）

生成一对 “配套密钥”——公钥（Public Key） 和私钥（Private Key）：

• 公钥：可以公开给任何人（像 “快递收件地址”），用于 “加密信息”；
• 私钥：仅限自己保存（像 “家里的钥匙”），用于 “解密用公钥加密的信息”；
• 关键规则：用公钥加密的密文，只能用对应的私钥解密；用私钥加密的密文，只能用对应的公钥解密。

• 优点：无需传输 “敏感的私钥”，解决了对称加密的 “密钥传输风险”，安全性更高。
• 缺点：算法复杂、运算速度慢，不适合加密 “大量数据”，通常用于 “传输对称密钥” 或 “身份验证”。
• 常见算法与应用：
  • RSA 算法（最主流）：用于 HTTPS 协议（浏览器地址栏的 “小锁”）、数字证书（如 SSL 证书）、SSH 远程登录（管理服务器）；
  • ECC 算法（更高效）：用于手机支付（如支付宝、微信支付）、区块链技术（如比特币）。

1.5 数据摘要

数据摘要（Data Digest），又称哈希值（Hash Value） 或消息摘要（Message Digest），是通过特定的哈希算法（Hash Algorithm） 对任意长度的原始数据（如文本、文件、图片等）进行处理后，生成的一段固定长度、唯一且不可逆的字符串。它的核心作用是验证数据的完整性和唯一性，而非用于数据保密（与加密不同）。

就与哈希表类似，两段不同的数据计算出来的哈希值相同的概率是极低的。

所以当数据被篡改时，计算出来的数据摘要大概率会发生变化。利用数据摘要进行验证，就可以在一定程度上验证数据的安全性，确保其没有被修改。

在确保数据摘要正确性的情况下：当数据摘要相同时，我们虽然不能肯定数据未被篡改，但是未被篡改的可能性高，此时我们选择相信；当数据摘要不同时，数据一定被篡改了，此时就不能相信。

显然，数据摘要可以用于本地的数据校验，例如验证数据库中的数据是否被修改过。但是，在HTTPS的网络数据传输中数据摘要又能发挥什么作用呢？这一点，我们将在下一个部分当中做出解释。

2. HTTPS的工作过程探究

如何加密才能有效保护数据在网络传输的过程当中不被监听、篡改呢？

首先，我们要明确，通信双方在通信之前就约定好中间人不知道的密钥，然后进行通信的方式是不切实际的。

想象一下，要使密钥不通过网络，也不进行公开（不能让中间人知道）就能传递到通信的另一方，那必然就存在另一种更加安全的通信手段，那还要网络干什么呢?

接下来我们会尝试逐步探讨如何对网络传输的数据进行加密。

2.1 只采用对称加密

即在通信之前，先约定好要使用的密钥，然后再进行加密通信。

但是很显然，密钥是完全暴露给中间人的，这样进行通信无非就是让中间人多花点时间来加密解密报文罢了。

2.2 只采用非对称加密

即客户端保留一个私钥，而只公开公钥。客户端用私钥加密报文，服务器用公钥解密；服务器用公钥加密，客户端用私钥解密。

如此一来，中间人就无法解密服务器回复的响应报文，保障了响应报文的安全性。

但是，缺点也很明显，那就是请求报文无法保密。虽然服务器发送给客户端的报文是保密的，但是中间人可以选择直接将服务器的响应报文丢弃，自己用公钥加密一个新的响应报文返回给客户端。

2.3 双方都采用非对称加密

采用非对称的方式可以保证单向的数据传输的保密（不安全，如上），那服务器和客户端都采用非对称的加密方式不就能保障两边的数据传输都保密了吗？

即，客户端和服务器都有自己的公钥和私钥，二者在通信之前先交换公钥。客户端用服务器的公钥进行数据加密，用自己的密钥进行解密；服务器同理。

这样一来，双方的信息都得到了保密，中间人就算想作假，他也会因为不知道双方到底在交流什么而无从下手（实际上也有办法，我们在2.4再指出这个问题）。

但是，非对称的加密存在着一个非常大的缺点，那就是加密解密的速度慢、效率低。

2.4 非对称加密 + 对称加密

在这个方案当中，通信双方通过非对称加密的方式来传送对称密钥，随后就使用对称密钥来传递信息。

1. 服务器拥有一对密钥S和S'。
2. 客户端想要进行通信时，先向服务端申请其公钥S。
3. 当客户端收到公钥S之后，用S将自己的公钥C进行加密，发送给服务器。
4. 随后，二者开始使用公钥C进行通信。

这样通信似乎很完美，但要是中间人彻底不当人，采用如下的手段，阁下又当如何应对呢：

1. 中间人自己拥有一对密钥M和M'。
2. 当服务器向客户端返回自己的公钥S时，中间人将S替换为自己的公钥M，返回给客户端。
3. 此时，客户端以为M就是服务器的公钥，于是客户端将自己的密钥C用M加密之后发送给服务器。
4. 中间人收到客户端传来的加密后的密钥C，使用自己的私钥M'即可将其解密。
5. 中间人再使用服务器的公钥S对密钥C进行加密，返还给服务器，服务器什么都察觉不到。
6. 到这时，客户端、中间人和服务器都知道密钥C，那么客户端和服务器之间的通信就毫无保留地暴露给了中间人。

同样的手段，也可以用来攻击2.3提出的方案，这里就不多赘述了。

3. HTTPS的工作原理

3.1 解决问题的第三方

现在，我们应该意识到一点：在只有客户端和服务器二者的情况下，中间人是立于不败之地的，因为其掌握着绝对的信息差！

所以，第三方的加入是必然的，这就是我们接下来要说的CA机构。但在此之前，我们先来讨论一下第三方能为通信双方带来些什么帮助。

首先我们要明确，这个第三方机构一定是广为人知的，以至于客户端与服务器都能不约而同地借助其来解决上面的问题。

我们注意到，问题的根源在于中间人将通信双方的最开始的公钥进行了篡改，而这个公钥只能采用明文的方式传送，这就给了中间人可乘之机。

于是，这个第三方可以是一个拥有着一对密钥（T和T'）的广为人知的机构，它将自己的公钥T公布出来，并负责为通信双方的公钥进行加密。

1. 在通信之前，服务器就请这个机构帮忙，使用T'将自己的公钥S进行加密。
2. 在客户端发起请求时，服务器就将加密之后的S传送给客户端。
3. 当被加密的的S被中间人截取时，中间人可以使用广为人知的T来进行解密，但是他无法篡改这个T，因为他没有密钥T'来对篡改后的密钥进行加密。

但此时还存在一个问题：那就是中间人也可以找这个第三方来加密自己的公钥，而第三方无法判断其加密的目的是为了安全通信还是去攻击别人。

所以，第三方加密的内容不能仅仅只有密钥，还应该带上服务器的域名、企业/单位、地址等验证信息。这样一来，即使中间人也找到第三方加密自己的公钥M，包含这个公钥M的数据包中的验证信息也能让客户端察觉到不对劲。

上面的做法有可行之处，但是对这样的数据包进行解密，对于整个建立连接的过程来说未免太耗时了。抛开非对称的加密方式不说，光是验证信息的大小就是密钥的许多倍。

这时，我们之前提到的数据摘要就派上用场了！实际上，我们想要的就是一个验证信息是否被篡改的方式。我们只要保证整个数据包的数字摘要未被篡改，就可以使用这个数字摘要来验证整个数据包是否被篡改。

所以，我们选择单独加密数字摘要，如此一来数据包的其余部分就都不用加密了，因为我们可以验证其是否被篡改。

这个被加密的数字摘要被我们称为“数字签名”（本身无法被篡改），而添加了数字签名的这个数据包则被我们称为“证书”（数字签名赋予其可信度）。

3.2 数字签名

数字签名（Digital Signature）本质是发送方用自己的私钥对数据进行的 “加密标记”，接收方通过对应的公钥验证该标记，从而确认两个核心信息：

1. 数据完整性：数据在传输过程中没有被篡改；
2. 发送方身份真实性：数据确实是声称的发送方发出的（不可否认性）。

数字签名的核心特点

• 不可伪造：只有持有发送方私钥的人才能生成有效的签名，他人无法伪造（私钥唯一且保密）。
• 不可否认：发送方无法否认自己发送过数据（因为签名由其私钥生成，公钥可验证）。
• 完整性保障：数据一旦被篡改，摘要会完全变化，验证时必然失败。
• 高效性：哈希算法生成的摘要长度远小于原始数据（如 SHA-256 生成 256 位摘要），直接对摘要签名可大幅节省计算和传输资源。

3.3 证书

数字证书（Digital Certificate）是由权威机构（CA）颁发的 “数字身份证”，证明 “某公钥确实属于某主体（个人 / 企业 / 服务器）”。

3.3.1 数字证书的结构

一份标准的数字证书（如遵循 X.509 协议的证书）包含以下关键信息，这些信息会被 CA 用自己的私钥签名，确保不可篡改：

• 证书持有者信息：公钥所属的主体（如网站域名、企业名称、个人姓名），明确 “这是谁的公钥”。
• 证书持有者公钥：需要被验证的公钥（如网站的 HTTPS 公钥、个人的签名公钥）。
• CA 信息：颁发证书的权威机构（如 Symantec、Let’s Encrypt、中国 CFCA）。
• CA 数字签名：CA 用自己的私钥对 “上述所有信息” 生成的数字签名（核心信任依据）。
• 证书有效期：证书的有效时间（如 1 年），过期后需重新申请。
• 证书序列号：CA 分配的唯一标识，用于查询证书状态（如是否被吊销）。

3.3.2 证书的签发与验证

证书的签发的核心步骤：

1. 生成证书摘要：CA 用哈希算法（如 SHA-256）对 “证书原文” 计算固定长度的摘要（如 256 位）—— 摘要唯一对应原文，任何微小篡改都会导致摘要完全不同；
2. CA 私钥加密摘要：CA 使用自己的 “根私钥”（或中间 CA 私钥，根 CA 私钥极少直接使用，避免泄露风险）对该摘要进行加密，加密后的结果即为 “数字签名”；
3. 绑定签名与证书：将 “数字签名” 附加到 “证书原文” 末尾，形成完整的 “数字证书”（通常为 PEM 或 DER 格式，如.crt、.pem 文件）。

证书的验证的核心步骤：

1. 提取证书原文与签名：终端从接收的证书中分离出 “证书原文” 和 “CA 的数字签名”；
2. 获取 CA 公钥：终端（如浏览器、操作系统）内置了权威 CA 的根公钥（如 Windows、macOS 预装了 Let's Encrypt、Symantec 等 CA 的公钥）—— 若证书是 “中间 CA 签发”（根 CA 通常不直接签发，避免根私钥风险），终端会先通过证书中的 “中间 CA 信息” 获取中间 CA 公钥，再层层验证到根 CA；
3. 解密签名并生成摘要：
   • 用 CA 公钥解密 “数字签名”，得到 CA 当初签发时计算的 “原始摘要”；
   • 用与 CA 相同的哈希算法（如 SHA-256）对 “当前接收的证书原文” 重新计算，得到 “新摘要”；
4. 对比摘要：若 “原始摘要” 与 “新摘要” 完全一致，证明证书原文未被篡改，且确是该 CA 签发；若不一致，判定证书被篡改或伪造，终端会弹出 “安全警告”（如浏览器提示 “此网站的证书无效”）。

3.4 HTTPS的方案

就是在2.4所提出的方案的基础上，服务器改为以证书的形式响应客户端对公钥的请求。

总结来说就是：证书 + 非对称加密 + 对称加密。