课程笔记：HTTPS原理——对称加密算法

课程名称：计算机网络应用 核心摘要：本讲为HTTPS安全原理系列第一讲，系统讲解对称加密算法的概念、三要素、加解密流程及常见算法（DES、3DES、AES），并结合Wireshark抓包分析TLS握手过程；深入剖析对称加密在密钥分发与维护上的固有缺陷，论证单独使用对称加密无法满足HTTPS安全需求，为后续非对称加密、数字签名等内容铺垫。

一、 核心概念与原理

1.1 对称加密定义

  • 对称加密（Symmetric Encryption），又称单密钥加密：加密与解密使用同一个密钥的加密算法。
  • 核心思想："你和我一样"——通信双方持有相同密钥，即可完成加解密。

1.2 对称加密三要素

要素说明示例
明文（Plaintext）待加密的原始数据"我喜欢吃鸡"
密钥（Key）密码系统中定长的字符串，长度由加密算法决定secret
算法（Algorithm）具体的加密/解密运算规则DES、AES 等

1.3 加解密流程

发送方：明文 + 密钥K ──[加密算法]──> 密文C ──[网络传输]──> 接收方
接收方：密文C + 密钥K ──[解密算法]──> 明文
  • 加密公式：X = F1(key, data)，其中 data 为明文，X 为密文，key 为密钥
  • 解密公式：data = F2(key, X)，使用同一密钥 key 还原明文
  • 核心安全依赖：密钥。只要密钥不泄露，整体通信安全。

二、 技术细节与协议分析

2.1 对称加密特性

特性说明
密钥长度通常 < 256 位；密钥越大越安全，但加解密效率越低
算法公开性必须公开——服务端与客户端需使用完全相同的算法
计算量相对较小，加密速度快（对比非对称加密）
安全性瓶颈仅一把密钥，密文与密钥同时被劫持则等同明文

关键原则：安全性以牺牲效率为代价。密钥越大 → 加密强度越高 → 加解密耗时越长。

2.2 常见对称加密算法对比

算法全称密钥特点安全性现状
DESData Encryption Standard单密钥，加密强度低可被暴力破解基本淘汰
3DESTriple DES三个密钥，对同一明文加密三次高于 DES维护3密钥成本高，效率低
AESAdvanced Encryption Standard（高级加密标准）128 / 256 位密钥当前公认最安全主流，浏览器普遍支持，苹果等广泛使用
RC4Rivest Cipher 4流加密算法已被证明不安全逐步弃用
BlowfishBlowfish可变密钥长度（32~448位）较高适用于部分场景

2.3 AES 版本对比

版本密钥长度加密轮数安全强度效率
AES-128128 位10 轮高较快
AES-256256 位14 轮更高较慢

密钥长度与加密轮数共同决定安全强度：256 位版本复杂度高于 128 位，但效率低于 128 位。

2.4 Wireshark 抓包分析 TLS 握手

通过 Wireshark 使用 tls 协议过滤器，可观察 HTTPS 建立过程：

  1. 第一步：Client Hello

    • 客户端（本地 IP）向服务端发送 Client Hello 报文
    • 携带客户端支持的对称加密算法列表（Cipher Suites）
    • 同时包含非对称加密算法列表

  2. Cipher Suites 字段解析

    • 协议：TLS 子协议——握手协议（Handshake Protocol）
    • 版本：TLS 1.0（示例抓包版本）
    • 密码套件列表中可见客户端支持的对称加密算法，例如：
      • AES-128 相关套件
      • AES-256 相关套件
Client Hello 报文结构
├── Handshake Protocol
│   ├── TLS Version: 1.0
│   ├── Cipher Suites（密码套件列表）
│   │   ├── AES-128-xxx
│   │   ├── AES-256-xxx
│   │   └── ...（含对称与非对称算法）
│   └── ...

双方需先协商出双方都支持的加密算法，才能进入后续加密通信。

三、 实践应用与配置命令

3.1 Wireshark 过滤命令

# 过滤 HTTP/2 协议
http2

# 过滤 TLS 协议层（观察握手过程）
tls

# 定位 Client Hello 报文
tls.handshake.type == 1

3.2 安全推演：单独使用对称加密的缺陷

场景假设：引入对称加密对传输数据加密，黑客拦截后无法破解。

加密：X = F1(key, data)   # key=密钥, data=明文, X=密文
解密：data = F2(key, X)   # 同一 key 解密

缺陷分析：密钥由服务端提供，需分发给客户端。

[服务端] ──key──> [黑客拦截] ──key──> [客户端]
                      │
                      ▼
               黑客持有 key，可解密所有密文
               形成"监听-转发"中间人攻击
  • 密钥你有、我有、他也有 → 加密等同不加密
  • 任何人可通过"合法方式"获取密钥 → 持有密钥即可解密

3.3 改进方案及问题

改进思路：服务端为每个客户端的 TCP 连接生成唯一密钥。

[客户端] ──请求key──> [服务端生成 K1]
[服务端] 存 K1，响应 K1 给客户端
[客户端] 存 K1
双向通信均用 K1 加密

两大问题：

问题详细说明
服务端维护成本高高并发场景下，1万个 TCP 连接 → 1万个 key，海量密钥存储与管理困难
客户端维护成本高且更危险客户端访问多个服务（拉勾K1、百度K2、微信支付K3...），本地需维护大量 key；黑客可通过木马程序窃取客户端密钥（服务器难攻，客户端易攻）

四、 重点与难点提示

  • 对称加密 = 单密钥加密：加解密使用同一密钥，这是最核心的特征。
  • 三要素：明文、密钥、算法——三者缺一不可。
  • AES 为当前主流：浏览器普遍支持，分 AES-128（10轮）与 AES-256（14轮）两版本。
  • DES 已淘汰：加密强度不足，可暴力破解；3DES 虽增强但效率低、维护成本高。
  • 密钥长度与效率的权衡：密钥越大越安全，但效率越低——安全以效率为代价。
  • 对称加密的致命缺陷：密钥分发问题——无法安全地将密钥传递给对方。
  • 改进方案仍不可行：每连接唯一密钥导致服务端/客户端双方维护成本过高，且客户端易被木马攻击。
  • 核心结论：单独使用对称加密无法满足 HTTPS 安全需求，需配合非对称加密、数字签名、证书等机制。
  • 易错点：对称加密速度快是相对非对称加密而言；算法必须公开（双方需使用同一算法）。

五、 课后疑问/遗留问题

  1. 既然对称加密无法单独保障安全，非对称加密如何解决密钥分发问题？（下讲内容）
  2. 数字签名、摘要算法如何配合对称加密构建完整 HTTPS 安全体系？
  3. 认证中心（CA） 与证书在 HTTPS 中扮演什么角色？
  4. TLS 握手协议完整流程（Client Hello 之后各步骤）详解？
  5. 实际 HTTPS 通信中，对称加密与非对称加密如何混合使用（混合加密体制）？
最近更新:
Contributors: yangwenguang