HTTPS简单来说是HTTP的升级版本。
那为什么需要HTTPS呢？

为什么需要 HTTPS？

HTTP 协议是明文的，这意味着在网络上传输的数据（如密码、信用卡号、聊天记录）就像一张明信片，经过的每个路由节点都可以窥探和篡改。这带来了三个核心风险：

• 窃听：通信内容被第三方获取。

• 篡改：通信内容被第三方修改。

• 冒充：第三方伪装成你通信的对方。

HTTPS 就是为了解决这三个问题而生的。它的目标是通过加密，建立一个安全的信息通道。

HTTPS 的基石：SSL/TLS

HTTPS 不是一个新的协议，而是 HTTP over SSL/TLS。简单来说，就是在 HTTP 通信外面套了一层 SSL/TLS 的加密外壳。

• SSL：安全套接层，目前已废弃（存在已知漏洞，如 POODLE）。

• TLS：传输层安全协议，是 SSL 的现代化后继者。我们现在说的 HTTPS 加密实际上都是指 TLS。

TLS 协议位于应用层（如 HTTP）和传输层（如 TCP）之间。

那运用了什么算法进行加密呢？

三大加密算法与它们的角色

HTTPS 的加密过程不是由单一算法完成的，而是巧妙地结合了三种不同类型的密码学算法，它们各司其职，扬长避短。

1. 非对称加密

• 核心思想：使用一对密钥——公钥和私钥。公钥可以公开给任何人，私钥必须严格保密。当然服务器持有私钥，客户端拿到公钥。

• 服务器：

  • 生成一对密钥（公钥和私钥）

  • 严格保密私钥，绝不外泄

  • 将公钥放入数字证书中

• 客户端（你的浏览器）：

  • 从服务器的数字证书中获取公钥

  • 用这个公钥来加密发送给服务器的信息

• 用公钥加密的数据，只有对应的私钥才能解密。

• 用私钥加密（签名）的数据，可以用公钥验证其真实性。

• 常见算法：RSA、ECDSA、DH（迪菲-赫尔曼密钥交换）

• 优点：解决了密钥分发问题，无需事先共享秘密。

• 缺点：计算速度非常慢，比对称加密慢几个数量级。

• 在 HTTPS 中的角色：主要用于身份验证和密钥交换。服务器将它的公钥放在数字证书中发给客户端，客户端用它来加密一个后续要用的“预主密钥”，确保只有拥有对应私钥的服务器才能解密它。

2. 对称加密

• 核心思想：加密和解密使用同一个密钥。

• 常见算法：AES（最常用）、ChaCha20、DES（已废弃）

• 优点：计算速度极快，适合加密大量数据。

• 缺点：密钥分发困难。如何让通信双方安全地拿到同一个密钥，而不被中间人窃取？

• 在 HTTPS 中的角色：在 TLS 握手完成后，所有应用数据（即 HTTP 报文）的加密都使用对称加密。因为通信速度是关键。

3. 散列算法

• 核心思想：将任意长度的数据映射为固定长度的、唯一的“指纹”（散列值）。它是一种单向函数，无法从散列值反推原始数据。

• 常见算法：SHA-256、SHA-384

• 在 HTTPS 中的角色：

  • 完整性校验：确保数据在传输过程中未被篡改。通过计算数据的散列值并一同传输，接收方可以重新计算并比对。

  • 构建消息认证码：与密钥结合使用（如 HMAC），用于验证消息的来源和完整性。

  • 数字签名：对证书的散列值进行签名。

这样理解散列算法还是有些困难。我们使用更通俗话术去进行理解。
散列算法就像一个 「数据指纹提取器」。

• 它的特点：

  • 任意输入 → 固定输出：无论原始数据是1MB还是1TB，都输出一个固定长度（如256位）的"指纹"（哈希值）。

  • 唯一性：只要输入数据有一丝一毫的改变（哪怕一个比特），输出的指纹就会完全不同。

  • 单向性：给你一个指纹，你绝对无法反推出原始数据是什么。哈希函数是单向的。✅数据 → 哈希值（容易）；❌ 哈希值 → 数据（不可能）。

在HTTPS中的用途：

• 完整性校验：服务器发送数据时，附带数据的哈希值。你收到后重新计算哈希，如果匹配，说明数据没被篡改。

• 制作数字签名：CA对证书的哈希值进行签名，而不是对整个证书签名。

• 密钥派生：用于从"预主密钥"生成最终的"会话密钥"。

比喻：就像一台神奇的榨汁机，你放进一个苹果（原始数据），它出来一杯苹果汁（哈希值）。你无法从苹果汁还原出苹果（单向性）。如果你放进去一个梨，出来的就是完全不同的梨汁（敏感性）。任何人给你一杯苹果汁，你都能验证它确实来自苹果（完整性）。

原始文件 → 计算SHA256 → 得到哈希值：abc123
下载的文件 → 计算SHA256 → 得到哈希值：abc123 ✓（文件完好）
如果得到：def456 ✗（文件被篡改或损坏）

简单哈希并不安全，中间人完全可以修改数据和哈希值。
错误的做法：

问题：中间人可以同时修改数据和哈希值，客户端无法察觉！

HTTPS中正确的做法：使用密钥化的哈希
HTTPS不使用简单的哈希，而是使用 HMAC 或 AEAD加密模式。

方法1：HMAC（基于密钥的哈希）

HMAC的工作方式：

• 服务器：发送 = 数据 + HMAC(数据, 会话密钥)

• 客户端：重新计算HMAC，与收到的对比

• 关键：只有知道会话密钥的双方才能计算出正确的HMAC

方法2：AEAD加密模式（现代TLS的标准做法）
更现代的方式是使用 AEAD 加密模式（如AES-GCM），它在加密时自动生成认证标签：

加密过程：
输入：明文数据 + 会话密钥
输出：密文 + 认证标签

解密过程：
输入：密文 + 认证标签 + 会话密钥
输出：明文数据（如果认证通过）或 错误（如果被篡改）

这就像一个有自检功能的加密信封：如果被拆开过，内容会自动销毁。

我们要知道加密通信的目的是什么？

• 就是让客户端和服务器安全地协商出同一个「会话密钥」，然后用这个密钥进行对称加密通信。

因为对称加密通信速度快，适合加密大量数据（比如网页内容、视频）

那为什么对称加密要比非对称加密快呢？
核心原因：数学问题的复杂性不同。

简单比喻：

• 非对称加密 像用手工雕刻一个极其复杂的锁芯，非常耗时。

• 对称加密 像用模具批量生产标准的钥匙，速度飞快。

因此，非对称加密可能比对称加密慢100到1000倍，所以只用在握手阶段，不用于加密大量数据。

数字证书：解决“公钥信任”问题

非对称加密的前提是，你拿到的公钥必须确实是你要通信的对方的公钥。否则，中间人可以替换掉服务器的公钥，进行中间人攻击。

数字证书就是为了解决“这个公钥是谁的”这个问题。它就像一个由权威机构颁发的电子身份证。

• 颁发者：证书颁发机构，全球公认的信任根（如 Let‘s Encrypt, DigiCert, GlobalSign）。

• 内容：包含服务器的域名、服务器公钥、颁发者、有效期等信息。

• 签名：CA 使用自己的私钥对整个证书内容进行数字签名。

你的操作系统和浏览器里预装了一份受信任的根证书列表。当浏览器收到服务器的证书时：

• 用 CA 的根公钥去验证证书上的签名。

• 如果签名验证通过，说明这个证书确实是可信的 CA 颁发的，且内容未被篡改。

• 浏览器还会检查证书中的域名是否与正在访问的域名一致，以及证书是否在有效期内。

这一切都通过后，浏览器才相信证书里的公钥确实是目标服务器的。

中间人会修改客户端中存在的证书吗？

答案是：极难直接修改，但可能通过其他方式影响证书验证。

让我们澄清一个关键点：这里说的"证书"有两种：
A. 客户端存储的"受信任根证书"
这些是操作系统/浏览器内置的权威CA证书。

• 中间人能直接修改吗？ 基本不可能

  • 这些证书存储在系统受保护区域

  • 修改需要管理员权限

  • 证书有自签名保护，修改会被发现

• 但攻击者可能通过其他方式：

  • 恶意软件：如果有恶意软件获得系统权限，可以添加伪造的根证书

  • 社会工程：诱导用户手动安装恶意根证书（如"请安装此证书以继续访问"）

  • 企业环境：企业可能强制安装监控证书

B. 服务器发送的站点证书
这是网站本身的证书，每次连接时服务器发送。

• 中间人能修改吗？ 技术上可以，但毫无意义

  • 中间人可以拦截并替换成自己的假证书

  • 但客户端会用内置的根证书验证这个假证书

  • 验证会失败，浏览器显示安全警告

中间人攻击证书的失败过程：

完整的 TLS 握手过程详解（以 RSA 密钥交换为例）

这是整个 HTTPS 加密通信建立的核心。下图清晰地展示了握手流程：

现在我们来分步解读图中的每一步：

第一步：TCP 连接建立
客户端（浏览器）首先通过 TCP 三次握手与服务器的 443 端口建立连接。

第二步：Client Hello
客户端向服务器发送一个问候消息，包含：

• 客户端支持的 TLS 版本（如 TLS 1.2, 1.3）。

• 客户端随机数：一个由客户端生成的随机字符串，用于后续密钥生成。

• 支持的密码套件列表：一个按优先级排列的算法组合列表，例如 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。这个套件说明了：

  • 密钥交换算法：ECDHE_RSA

  • 身份验证算法：RSA

  • 对称加密算法：AES_128_GCM

  • 散列算法：SHA256

在第二步中中间人会看到这些信息，但是却无法有效伪装。
攻击者的机会与限制：

• 窃听：攻击者完全可以看到所有这些信息。

• 伪装成服务器：极其困难

  • 攻击者可以拦截通信，并发送自己的假证书给客户端

  • 但客户端的浏览器会立即发现这个证书不是由可信CA签发的，或者域名不匹配

  • 浏览器会显示安全警告（如"此连接非私密连接"），阻止用户继续

  • 除非用户刻意忽略警告，否则攻击无法继续

第三步：Server Hello
服务器响应客户端的问候，内容包括：

• 确认使用的 TLS 版本。

• 服务器随机数：一个由服务器生成的随机字符串。

• 选定的密码套件：从客户端提供的列表中选出一个。

第四步：Server Certificate & Server Hello Done
服务器将自己的数字证书发送给客户端。之后发送 Server Hello Done 表示服务器问候结束。

第五步：客户端验证证书与发送预主密钥

• 客户端验证服务器的证书（验证签名、有效期、域名等）。

• 验证通过后，客户端生成第三个随机数，称为 “预主密钥”。

• 客户端从证书中提取出服务器的公钥，用它来加密这个预主密钥，然后将加密后的结果作为 Client Key Exchange 消息发送给服务器。

第六步：服务器解密预主密钥
服务器用自己的私钥解密 Client Key Exchange 消息，得到明文的“预主密钥”。

至此，一个关键的里程碑达成了：客户端和服务器现在共享三个秘密值：客户端随机数、服务器随机数和预主密钥。它们双方会使用相同的密钥派生函数，根据这三个值生成最终的主密钥，进而派生出用于后续对称加密的会话密钥。

第七步：切换至加密通信

• 客户端发送 Change Cipher Spec 消息，通知服务器：“从现在开始，我们之后所有的通信都将使用刚刚协商的会话密钥进行加密”。

• 客户端紧接着发送一个 Finished 消息，这条消息本身是加密的，它包含了之前所有握手消息的摘要，供服务器校验。

第八步：服务器确认切换

• 服务器同样发送 Change Cipher Spec 消息。

• 服务器发送加密的 Finished 消息。

客户端解密并验证服务器的 Finished 消息。

第九步：安全通信建立
TLS 握手完成！一个安全的、加密的通道已经建立。此后，所有的 HTTP 请求和响应（应用层数据）都将使用高效的对称加密算法（如 AES）进行加密传输。

用更简洁的图表进行显示过程：

为了更好理解此过程，我们打个比喻：

比喻：寄送保密信件

想象一下，你想和朋友「阿服务器」互相寄送加密的日记。但邮路不安全，可能会被偷看（窃听）、篡改（篡改），甚至有人冒充阿服务器（冒充）。

你们的终极目标是：商量出一个只有你俩知道的、相同的「密码本」，以后所有日记都用这个密码本加密。这样就算信件被截获，别人也看不懂。

流程：

第1步：打招呼与验明正身

• 你（客户端）说： “你好阿服务器！我叫小明。我会 AES、RSA 这些加密方法，我们用什么方式交流最安全？”（Client Hello）

• 阿服务器（服务器）回复：

• “你好小明！我们就用 AES_256_GCM 这个方案吧。”（Server Hello）

• 【关键动作】 同时，他寄来了他的 【数字证书】，这就像他的 「身份证」 。

  • 证书里有什么？ 他的网站名 aserver.com 和一把 「公钥锁」。

  • 谁颁发的？ 由全球公认的 「证书管理局」 颁发的，上面有管理局的防伪印章（数字签名）。

• 你做什么？ 你拿出你信任的**「证书管理局」**名单，核对这张身份证的真伪。确认无误后，你相信这把「公钥锁」确实是阿服务器的。

✅ 这一步解决了「冒充」问题：你确认了通信的对方就是真正的阿服务器。

第2步：传递「密码本」的原料

• 你（客户端）的操作：

  • 你心里想好一个绝密的数字（比如 12345），这就是 「预主密钥」，它是制作最终「密码本」的核心原料。

  • 你用从证书里拿到的那把 「公钥锁」，把这个绝密数字锁在一个小铁盒里。

• 你将这个锁好的铁盒寄给阿服务器。（Client Key Exchange）

🔒 这一步解决了「窃听」问题：即使铁盒在途中被偷，因为没有阿服务器的私钥钥匙，谁也打不开它。

第3步：各自配制出相同的密码本

• 阿服务器（服务器）的操作： 他收到铁盒后，用只有他自己才有的 「私钥钥匙」 打开铁盒，拿到了那个绝密数字（12345）。

• 此时，神奇的事情发生了： 你和阿服务器现在都拥有了相同的「原料」：

  • 绝密数字（预主密钥）

  • 第一步打招呼时生成的随机数

  • 相同的算法

你们双方用这些原料，各自独立地计算出同一把最终的「会话密钥」（即那个密码本）。

🔑 这一步的核心是：秘密（预主密钥）被安全传递，并在此基础上生成了用于高速通信的对称密钥。

第4步：开始安全通信

• 你（客户端）说： “好了，我们以后就用这个密码本通信吧！”（Change Cipher Spec）然后你发了第一条用密码本加密的测试消息：“今天是晴天”（Finished）。

• 阿服务器（服务器）回复： “明白！我也切换到密码本模式。”他也回了一条加密的测试消息。

双方解密测试消息成功，确认密码本一致，通道安全！

• 从此以后，你们所有往来的日记（HTTP 数据），全部都用这个 「密码本」（对称加密） 进行加密和解密，速度快且安全。

✅ 这一步最终解决了「窃听」和「篡改」问题，因为所有内容都已加密，且任何改动都会被发现。

HTTPS中完整性保护流程

小结

HTTPS 就是这样，通过一次安全的「握手」，巧妙地结合了非对称加密（安全交换密钥）和对称加密（高效加密数据）的优点，为我们的网上冲浪保驾护航。

更先进的密钥交换：ECDHE 与前向保密

上述过程使用的是 RSA 密钥交换。但更现代、更安全的方式是 ECDHE（椭圆曲线迪菲-赫尔曼密钥交换）。

• 前向保密：即使有一天服务器的私钥被泄露，攻击者也无法解密之前截获的通信记录，因为每次会话的“预主密钥”都是临时生成的，且没有用服务器私钥加密。

• 过程：在 ECDHE 交换中，服务器和客户端会临时生成一对公私钥，通过数学计算（迪菲-赫尔曼原理）共同推导出相同的“预主密钥”，而无需在网络上直接传输它。这个临时密钥在会话结束后就销毁了。

TLS 1.3 已经强制要求使用支持前向保密的密钥交换算法（如 ECDHE），并废除了 RSA 密钥交换。

小结

HTTPS 的加密是一个精妙的系统工程：

• 身份验证：通过 数字证书 和 非对称加密 确保你连接的是正确的服务器，而不是中间人。

• 密钥交换：通过 非对称加密（RSA）或 密钥协商算法（ECDHE）安全地协商出一个只有双方知道的共享秘密。

• 数据加密：使用协商出的共享秘密生成会话密钥，然后用高效的对称加密算法来加密所有通信数据，保证机密性。

• 完整性保护：使用散列算法 确保数据在传输过程中未被篡改。

这套组合拳完美地利用了各种算法的优势，规避了其劣势，最终为我们日常的网页浏览、支付、通讯构建了一道坚实的安全屏障。