HTTPS 加密原理与实践

HTTP 本身是明文传输协议，中间人可以轻易窃听或篡改请求与响应内容。HTTPS 在 HTTP 之上增加了 TLS 加密层，为 Web 通信提供了「机密性、完整性与身份验证」。

本文从实用角度出发，讲清楚：

• HTTP 与 HTTPS 的核心差异
• 对称加密、非对称加密与数字证书在 HTTPS 中各自扮演什么角色
• TLS 握手的大致流程与关键步骤
• 浏览器如何验证证书？中间人攻击是如何被防御的？
• 前端/后端在工程中需要注意什么？

---

一、HTTP 有哪些安全问题？

HTTP 明文传输意味着：

• 窃听：中间人可以看到你传输的所有内容（账号密码、Cookie、接口数据等）
• 篡改：中间人可修改请求/响应（注入广告、恶意脚本、掉包资源）
• 伪造：用户无法确认对端身份，可能访问的是“伪装网站”

这些风险在公共 Wi-Fi、运营商出口、跨境链路等情况下尤为严重。

---

二、HTTPS 的三大目标

HTTPS 通过 TLS（Transport Layer Security）实现三大安全目标：

1. 机密性（Confidentiality）：内容被加密，第三方看不懂
2. 完整性（Integrity）：内容未被篡改，否则可被检测出来
3. 身份验证（Authentication）：确认服务端是“真的那个网站”

这背后用到了三类核心技术：

• 对称加密
• 非对称加密
• 数字签名与证书体系（PKI）

---

三、对称加密与非对称加密

1. 对称加密

• 加密与解密使用同一个密钥（secret key）
• 常见算法：AES、ChaCha20 等
• 优点：速度快，适合大数据量加密
• 缺点：如何安全交换密钥本身是个难题

2. 非对称加密

• 有一对密钥：公钥与私钥
• 公钥加密 → 私钥解密；私钥签名 → 公钥验证
• 常见算法：RSA、ECDSA、ECDH
• 优点：可以在不泄露私钥的前提下建立安全通信
• 缺点：运算慢，不适合大数据量加密

3. HTTPS 的折中方案

使用非对称加密 安全协商出一个对称加密密钥，后续数据传输使用对称加密。

这就同时兼顾了「安全」与「性能」。

---

四、数字证书与 CA 信任链

1. 数字证书是什么？

一个站点的数字证书（如 sunjc.vip 的证书）大致包含：

• 网站的公钥
• 网站的域名信息（Subject）
• 证书的有效期
• 颁发机构（Issuer，CA）
• CA 对以上信息做出的数字签名

2. CA（证书颁发机构）与信任链

浏览器/操作系统内置了一批“根证书”（Root CA），它们是系统默认信任的机构。

当你访问 https://sunjc.vip 时：

1. 服务器会把站点证书发给浏览器
2. 浏览器查看证书是由哪家 CA 颁发的
3. 找到对应的中间 CA/根 CA 公钥
4. 用 CA 公钥验证证书上的签名是否正确

只要整个“证书链”都能被信任，就认为证书是可信的。

3. 域名与证书匹配

除了签名合法，浏览器还会验证：

• 当前访问的域名是否在证书的 CN / SAN（Subject Alternative Name） 列表中
• 证书是否在有效期内
• 是否被吊销

如果不匹配，就会出现常见的“证书错误”警告。

---

五、TLS 握手的大致流程（以 TLS1.2 为例，简化版）

一个典型的 HTTPS 建连（TLS1.2）流程可简化为：

1. ClientHello
   • 客户端（浏览器）发起，告知支持的协议版本、加密套件列表等
2. ServerHello
   • 服务端从中选定一个加密套件，返回给客户端
   • 同时发送服务器证书（含公钥）
3. 客户端验证证书
   • 验证证书签名、有效期、吊销状态、域名匹配等
   • 验证通过后，客户端生成一个随机对称密钥（或通过密钥交换算法协商出共享密钥）
4. 密钥协商
   • 客户端使用服务器公钥（或密钥交换算法，如 ECDHE）加密协商信息，发给服务器
   • 服务器使用私钥解密，得到对称密钥
5. 双方确认后续通信加密
   • 使用协商好的对称密钥，对后续 HTTP 报文进行加解密

TLS1.3 在此基础上进一步简化了握手流程：

• 合并多次往返
• 默认使用更安全的密钥交换算法（如 ECDHE）
• 弃用一些不安全的旧算法与特性

---

六、HTTPS 如何防御中间人攻击？

中间人攻击（MITM，Man-in-the-middle）大致长这样：

1. 攻击者拦截你与服务器之间的流量
2. 与服务器建立一个正常的 HTTPS 连接（自己做客户端）
3. 与你建立另一个“伪造证书”的 HTTPS 连接（自己做服务端）
4. 在两头转发数据，并可窃听或篡改内容

关键防御点在于“证书验证”：

• 攻击者无法拿到目标网站的私钥
• 无法伪造出由“受信任 CA”签名的合法证书
• 浏览器会发现证书签名不对、或证书链不受信任，从而弹出安全警告

除非：

• 用户主动安装了攻击者的根证书（如公司代理、恶意软件），或
• 用户无视浏览器的严重安全警告强行继续访问

否则中间人无法在不被发现的情况下成功攻击。

---

七、前端开发需要关心什么？

1. 全站 HTTPS 与混合内容

当页面通过 HTTPS 访问时，若仍加载 HTTP 资源，会触发“混合内容（Mixed Content）”警告，甚至被浏览器拦截：

• 主动混合内容（如通过 HTTP 加载 JS/CSS）通常会被直接阻止
• 被动混合内容（如图片）也越来越多地被禁止

前端需确保：

• 所有静态资源（JS、CSS、图片、字体、接口请求）均使用 HTTPS
• 第三方 SDK / 接口也都是 HTTPS

2. Cookie 安全属性

在 HTTPS 站点上，应设置：

• Secure：Cookie 只通过 HTTPS 发送
• HttpOnly：防止被 JS 读取，降低 XSS 窃取风险
• SameSite：减少 CSRF 攻击面（如 Lax / Strict / None; Secure）

示例：

Set-Cookie: sessionId=xxx; Secure; HttpOnly; SameSite=Lax

3. HSTS（HTTP Strict Transport Security）

服务器可通过响应头宣告：

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

含义：

• 在接下来一段时间内（如 1 年），该域名必须通过 HTTPS 访问
• 即使用户输入 http://，浏览器也会自动升级为 https://

这可以防御某些“第一次访问被劫持”的情况。

---

八、后端与运维侧的注意点（简述）

• 使用自动化工具（如 Let’s Encrypt、certbot 或 acme 客户端）实现证书自动申请与续期
• 确保使用现代安全的 TLS 配置：
  • 禁用已知不安全的协议版本（如 TLS1.0/1.1）
  • 禁用弱加密套件
  • 优先使用 ECDHE + AESGCM 或 ChaCha20-Poly1305
• 在 Nginx/负载均衡层统一终止 TLS，后端走内网通信

---

九、总结

HTTPS 的核心是通过 TLS + 证书体系 为 HTTP 通信提供安全保障：

• 机密性：利用对称加密保护数据不被窃听
• 完整性：利用 MAC/AEAD 等机制检测数据是否被篡改
• 身份验证：利用证书链与 CA 信任体系确认服务器身份

作为前端开发者，虽然不需要手写 TLS 协议，但需要在工程实践中注意：

• 全站 HTTPS，避免混合内容
• 正确设置 Cookie 与 HSTS
• 配合后端/运维保证证书与 TLS 配置的安全

理解这些原理，有助于你更好地回答与网络安全相关的面试问题，也能在实际项目中做出更安全的技术决策。