重要

HTTPS 通过混合加密（非对称加密协商密钥 + 对称加密传输数据）和数字证书（CA 签名验证服务器身份）解决 HTTP 的安全问题。核心：三个随机数生成会话密钥，CA 证书防御中间人攻击。

1.简介

HTTP存在三大安全问题：明文传输（窃听）、无法验证身份（伪装）、无法验证完整性（篡改）。

HTTPS通过TLS/SSL协议在HTTP基础上增加加密层，解决这三大问题。演化过程：

1.1 单向非对称加密（不可行）

流程：

1. 浏览器 –(request.明文)–> 服务器
1. 服务器 –(response.明文)–> 浏览器
1. 服务器 –(公钥.server)–> 浏览器
1. 浏览器 –(request.密文-公钥加密)–> 服务器

问题：

服务器返回的响应仍然是明文（私钥加密等于公开，任何人都能用公钥解密）
无法保证服务器到客户端方向的安全

1.2 双向非对称加密（不可行）

流程：

1. 浏览器 –(request.明文)»> 服务器
1. 浏览器 «(response.明文)– 服务器
1. 浏览器 «(公钥.server)—- 服务器
1. 浏览器 –(公钥.client)»» 服务器
1. 浏览器 –(request.密文-公钥.server加密)»> 服务器
1. 浏览器 «(response.密文-公钥.client加密)— 服务器

问题：

非对称加密性能差（比对称加密慢约1000倍）
服务器需要管理每个客户端的公钥（不现实）

1.3 混合加密（对称+非对称）

三个随机数：Client Random（明文） + Server Random（明文） + Premaster Secret（加密）→ 双方各自派生相同的会话密钥。前两个防止重放攻击，第三个防止中间人窃取。

随机数1 = Client Random（客户端生成，明文）
随机数2 = Server Random（服务器生成，明文）
随机数3 = Premaster Secret（客户端生成，加密）

流程（双方状态变化）：

1. [ ]浏览器[随机数1 ] –(随机数1.明文)»»»»»»»»»> [ ]服务器[私+公钥.server]
1. [ ]浏览器[随机数1 ] «(随机数2.明文)——————- [随机数1+2 ]服务器[私+公钥.server]
1. [ ]浏览器[随机数1+2 ] «(公钥.server)——————- [随机数1+2 ]服务器[私钥.server]
1. [公钥.server]浏览器[随机数1+2+3] –(随机数3.密文-公钥.server加密)»» [随机数1+2 ]服务器[私钥.server]
1. [公钥.server]浏览器[随机数1+2+3] –(finish.密文-随机数计算秘钥)»»» [随机数1+2+3]服务器[私钥.server]
1. [公钥.server]浏览器[随机数1+2+3] «(finish.密文-随机数计算秘钥)—— [随机数1+2+3]服务器[私钥.server]
1. [公钥.server]浏览器[随机数1+2+3] –(request.密文-随机数计算秘钥)»»> [随机数1+2+3]服务器[私钥.server]
1. [公钥.server]浏览器[随机数1+2+3] «(response.密文-随机数计算秘钥)—- [随机数1+2+3]服务器[私钥.server]

上述流程展示了双方持有的密钥材料和状态变化，方括号内为当前持有的密钥/随机数

会话密钥生成：

1
2
3
Master Secret = PRF(premaster_secret, "master secret", 
                    client_random + server_random)
会话密钥 = 从 Master Secret 派生

优点：

非对称加密只用于协商密钥（性能影响小）
对称加密用于数据传输（性能好）

问题：

无法验证服务器身份，存在中间人攻击风险

1.4 数字证书（最终方案）

引入CA（Certificate Authority，证书颁发机构）解决公钥信任问题。

数字证书的本质：CA 用自己的私钥对「服务器公钥 + 域名」做签名，浏览器用 CA 公钥验证签名，确认该公钥确实属于该域名。

服务器向CA申请证书流程：

服务器生成密钥对（公钥+私钥）
1
openssl genrsa -out server.key 2048
服务器生成CSR（证书签名请求）
1
openssl req -new -key server.key -out server.csr
CSR包含：服务器公钥、域名、组织信息，但不包含私钥
服务器向CA提交CSR
私钥留在服务器本地，从不发送给CA
CA验证服务器身份（DNS验证或HTTP验证）
CA用自己的私钥对CSR内容生成数字签名
CA颁发证书（包含：服务器公钥、服务器信息、CA数字签名）
服务器收到证书，配置HTTPS（私钥+证书）

浏览器验证证书：

检查证书有效期
检查证书域名是否匹配
检查CA是否在浏览器信任列表中
用CA公钥解密数字签名，验证服务器信息未被篡改

中间人攻击防御：

中间人无法伪造CA签名（没有CA私钥）
即使中间人替换证书，浏览器验证签名会失败
CA公钥内置在操作系统/浏览器中（信任锚点）

2.完整TLS握手流程

综合混合加密和数字证书，完整的TLS 1.2握手流程：

TLS 1.2 握手核心：① 交换随机数 → ② 验证证书 → ③ 加密传输 Premaster Secret → ④ 双方派生会话密钥 → ⑤ 对称加密通信。整个过程 2-RTT。

客户端                                      服务器
  |                                           |
  |---(1) Client Hello ---------------------->|
  |    [支持的加密套件、随机数1]                |
  |                                           |
  |<--(2) Server Hello -----------------------|
  |    [选定的加密套件、随机数2]                |
  |                                           |
  |<--(3) Certificate ------------------------|
  |    [服务器证书，包含公钥和CA签名]           |
  |                                           |
  |<--(4) Server Hello Done ------------------|
  |                                           |
  |---(5) 客户端验证证书                        |
  |    [检查有效期、域名、CA签名]               |
  |                                           |
  |---(6) Client Key Exchange --------------->|
  |    [随机数3，用服务器公钥加密]              |
  |                                           |
  |---(7) Change Cipher Spec ---------------->|
  |    [通知：后续使用协商的密钥加密]           |
  |                                           |
  |---(8) Finished (加密) -------------------->|
  |    [握手消息的hash，验证密钥正确]          |
  |                                           |
  |<--(9) Change Cipher Spec -----------------|
  |                                           |
  |<--(10) Finished (加密) --------------------|
  |                                           |
  |<===(11) 应用数据 (对称加密) ==============>|

关键步骤说明：

步骤	操作	说明
1-2	Hello消息	协商加密算法，交换随机数1、2
3	发送证书	服务器证明身份
5	验证证书	客户端验证服务器身份
6	密钥交换	传输随机数3（加密）
7-10	切换密钥	双方确认密钥协商成功
11	应用数据	使用对称加密通信

3.数字证书详细说明

3.1 证书链

实际应用中使用证书链结构：

根证书CA (Root CA)
    └── 中间证书CA (Intermediate CA)
            └── 服务器证书 (Server Certificate)

证书链的作用：保护根CA私钥

不使用证书链的问题：

根CA私钥需要频繁使用（签发大量服务器证书）
暴露风险高，一旦泄露影响所有信任该根CA的系统
需要全球范围更新操作系统/浏览器（灾难性后果）

使用证书链的优势：

层级	私钥保护	使用频率	泄露影响	补救措施
根CA	物理隔离、冷存储、HSM	极少（只签中间CA）	灾难性（需全球更新）	几乎无法补救
中间CA	在线签名服务器	频繁（签服务器证书）	可控（撤销该中间CA）	重新申请证书
服务器	服务器本地	持续使用	局部（只影响该站点）	吊销并重新申请

撤销中间CA的影响：

该中间CA签发的所有服务器证书立即失效
所有受影响的服务器需要向其他中间CA重新申请证书
虽然影响范围大，但比根CA泄露的影响小得多
实际案例：2011年DigiNotar CA被攻破，根证书被浏览器移除

验证过程：

验证服务器证书（用中间CA公钥）
验证中间CA证书（用根CA公钥）
根CA证书内置在系统中（自签名，信任锚点）

类比：根CA私钥像银行总行保险柜钥匙（几乎不用），中间CA私钥像分行钥匙（日常使用，出问题可撤销并换其他分行）

3.2 证书内容

证书包含的信息：

字段	说明	示例
版本	X.509版本	v3
序列号	证书唯一标识	0x1234…
签名算法	CA签名使用的算法	sha256WithRSAEncryption
颁发者	CA信息	CN=DigiCert SHA2
有效期	起止时间	2023-01-01 to 2024-01-01
主题	服务器信息	CN=example.com
公钥	服务器公钥	RSA 2048位
数字签名	CA签名	加密的hash值

3.3 实际操作

查看证书信息：

1
2
3
4
5
6
7
8
# 查看网站证书
openssl s_client -connect example.com:443 -showcerts

# 查看证书详细信息
openssl x509 -in cert.pem -text -noout

# 验证证书有效性
openssl verify -CAfile ca.pem cert.pem

生成自签名证书（开发环境）：

1
2
3
4
5
6
7
8
9
# 生成私钥
openssl genrsa -out server.key 2048

# 生成证书签名请求
openssl req -new -key server.key -out server.csr

# 生成自签名证书
openssl x509 -req -days 365 -in server.csr \
  -signkey server.key -out server.crt

自签名证书浏览器会提示不安全，生产环境需要使用正规CA签发的证书

4.总结

HTTPS通过以下机制保证安全：

混合加密：非对称加密协商密钥，对称加密传输数据
三个随机数：Client Random + Server Random + Premaster Secret生成会话密钥
数字证书：CA签名验证服务器身份，防御中间人攻击
证书链：根CA → 中间CA → 服务器证书，层层验证

关键点：

非对称加密只用于握手阶段（性能影响小）
会话密钥由三个随机数派生（双方参与，足够随机）
CA公钥内置在系统中（信任根源）
中间人无法伪造CA签名（没有CA私钥）

常见问题：

Q: 为什么不直接用非对称加密传输数据？
A: 性能差，非对称加密比对称加密慢约1000倍。

Q: 三个随机数为什么不能少？
A: 前两个明文传输（让双方参与），第三个加密传输（防止中间人获取）。

Q: CA证书过期或被撤销怎么办？
A: 浏览器通过CRL（证书撤销列表）或OCSP（在线证书状态协议）检查证书状态。

Q: HTTPS就完全安全了吗？
A: HTTPS只保证传输层安全，应用层漏洞（SQL注入、XSS等）仍然存在。

5.扩展

5.1 TLS版本

版本	发布时间	主要改进
TLS 1.0	1999	SSL 3.0升级版
TLS 1.1	2006	防御CBC攻击
TLS 1.2	2008	支持SHA-256
TLS 1.3	2018	简化握手，提升性能

TLS 1.3主要改进：

握手只需1个RTT（1.2需要2个）
移除不安全的加密算法
默认使用前向保密

5.2 性能优化

Session复用：

Session ID：服务器缓存会话信息
Session Ticket：客户端持有加密的会话信息

OCSP Stapling：

服务器主动提供证书状态
避免客户端查询OCSP服务器

HTTP/2：

多路复用，减少连接数
头部压缩，降低开销

目录

Https流程说明

重要