【网络基础-03】HTTPS与TLS

Sion_Ze
0 阅读9分钟

HTTPS与TLS探讨

HTTP 是明文传输。HTTPS = HTTP + SSL/TLS，在 HTTP 与 TCP 之间插一层安全层，提供 「加密、认证、完整性」 三大保护，从网络协议的安全石。在安全视角逐步拆解 TLS 握手全过程、证书链验证、加密套件命名规则，理解中间人攻击、心脏滴血等经典漏洞。

一、为什么需要 HTTPS

HTTP 明文传输，存在三大风险：

  1. 窃听：在咖啡馆 Wi-Fi 下抓包就能看到密码、Cookie 等敏感信息；
  2. 篡改：ISP 或路由器可在响应中插入广告、恶意脚本（运营商劫持）；
  3. 冒充：钓鱼网站可冒充真站，用户难辨真假。

HTTPS = HTTP + SSL/TLS，在 HTTP 与 TCP 之间插一层安全层，提供三大保护：

  • 加密（Confidentiality）：数据密文传输，窃听者看不懂；
  • 认证（Authentication）：通过证书证明服务器身份，防冒充；
  • 完整性（Integrity）：校验数据未被篡改。

http和HTTPS对吧.png

HTTPS 默认端口 443，URL 方案为 https://。SSL（Secure Sockets Layer）是网景公司早期版本，TLS（Transport Layer Security）是其继任者（TLS 1.0 ≈ SSL 3.1）。现在统称 TLS，SSL 已废弃。

二、加密基础

2.1 对称加密

原理：加密和解密用同一把密钥。

  • 代表算法：DES（已不安全）、3DES、AES（主流）、RC4（已不安全）、ChaCha20；
  • 优点：速度快，适合大数据量加密；
  • 缺点：密钥分发问题——双方得先把密钥安全地约定好，但网络上没法安全传密钥（鸡生蛋问题）。

类比：对称加密像带锁的箱子，锁和钥匙是同一把。你想给朋友寄箱子，得先把钥匙给他，但寄钥匙的路上钥匙又可能被偷——这就是密钥分发难题。

2.2 非对称加密

原理：一对密钥——公钥（public key）可公开，私钥（private key）保密。用公钥加密的数据只能用私钥解密；反之用私钥「签名」的数据可用公钥「验签」。

  • 代表算法：RSA、ECC（椭圆曲线，更短密钥同等安全）、DSA；
  • 优点：解决密钥分发问题（公钥可随便公开）；
  • 缺点：速度慢（比对称加密慢 100~1000 倍），不适合大数据量。

类比：非对称加密像信箱——任何人都能把信塞进信箱（公钥加密），但只有信箱主人有钥匙能打开取信（私钥解密）。

数字签名：发送方用自己的私钥对数据签名，接收方用发送方的公钥验签。这样能证明「这数据确实是发送方发的，且没被篡改」（防否认+完整性）。注意：加密用对方公钥，签名用自己私钥，别搞反。

2.3 哈希算法

原理：把任意长度数据映射成固定长度的「指纹」（摘要），不可逆。

  • 代表算法：MD5（128位，已不安全）、SHA-1（160位，已不安全）、SHA-256（主流）、SHA-3；
  • 特点：单向（不可逆）、定长输出、抗碰撞（不同输入很难得到相同输出）；
  • 用途：完整性校验、密码存储（应加盐）、数字签名（对摘要签名而非全数据，提高速度）。

2.4 混合加密

实际 HTTPS 用混合加密：先用非对称加密协商出对称密钥（会话密钥），之后用对称密钥加密业务数据。这样兼顾安全与性能——非对称解决密钥分发，对称负责高效加密。

三、TLS 握手详细过程（重点）

以 TLS 1.2 RSA 密钥交换为例，握手流程如下。

TLS 1.2 RSA 密钥交换.png

各步详解

① ClientHello（客户端打招呼）
客户端发送：支持的 TLS 版本（如 TLS 1.2）、支持的加密套件列表、客户端随机数 ClientRandom（32 字节，用于后续密钥派生）、Session ID（可选，用于会话复用）。

② ServerHello + 证书（服务器回应）
服务器返回：选定的 TLS 版本、选定的加密套件（从客户端列表里挑一个）、服务器随机数 ServerRandom、服务器证书（X.509，内含公钥和 CA 签名）。可选发 ServerKeyExchange（DH 参数）和 ServerHelloDone。

③ 客户端验证证书 + 密钥交换
客户端先验证证书（见下节「证书链验证」）。验证通过后，客户端生成一个 PreMasterSecret（预主密钥，48 字节），用服务器证书里的公钥加密后发回服务器（RSA 密钥交换）。若用 DH/ECDHE，则客户端发自己的 DH 公钥。接着发 ChangeCipherSpec（通知「之后我都加密了」）和 Finished（加密的第一条消息，含握手摘要供对方校验）。

④ 服务器确认
服务器也发 ChangeCipherSpec 和 Finished。握手结束。

最终密钥如何生成

双方都有了三个随机数：ClientRandom、ServerRandom、PreMasterSecret。用这三个数按特定算法（PRF）派生出主密钥 MasterSecret，再派生出会话密钥（含客户端写密钥、服务器写密钥、客户端写 MAC 密钥、服务器写 MAC 密钥）。三个随机数的作用：保证每次会话密钥都不同，即使某次密钥泄露也不影响其他会话。

TLS 1.3 的改进

TLS 1.3 把握手压缩为 1-RTT（甚至 0-RTT），去掉了 RSA 密钥交换（不支持前向安全的方案）、MD5/SHA-1 等弱算法，强制使用 ECDHE 等前向安全密钥交换，精简了加密套件。

四、证书链验证

证书由 CA（Certificate Authority，证书颁发机构） 签名。浏览器/操作系统内置了一组「根 CA」的公钥（自签名，可信锚点），形成信任链：

根 CA（自签名，浏览器/OS 内置）
   │ 签发
   ▼
中间 CA（如 Let's Encrypt 的中间证书）
   │ 签发
   ▼
网站证书（www.example.com，含公钥）

浏览器验证网站证书时：

  1. 检查有效期：notBefore/notAfter 是否在当前时间区间内；
  2. 用上级 CA 公钥验签：验证证书上的 CA 签名是否合法（即「这证书确实是上级 CA 签的」）；
  3. 逐级追溯：中间 CA → 根 CA，直到根 CA 在浏览器内置列表里（信任锚）；
  4. 核对域名：证书的 Common Name 或 Subject Alternative Name 是否匹配访问的域名；
  5. （可选）检查吊销：通过 OCSP（在线证书状态协议）或 CRL（证书吊销列表）查询证书是否被吊销。

《HTTP权威指南》指出 X.509 v3 证书包含字段：版本、序列号、签名算法、颁发者、有效期、主体（域名）、主体公钥、扩展、CA 签名。

自签名证书：自己签自己，不在浏览器信任链里，浏览器会报「不安全」警告。内网测试可用，公网不可用。

五、加密套件

加密套件（Cipher Suite）命名形如 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256，由四部分组成：

  • 密钥交换（Kx）：ECDHE（临时椭圆曲线 DH，前向安全）、RSA、DHE；
  • 认证（Au）：RSA、ECDSA（用哪种算法验证书签名）；
  • 加密（Enc）：AES-128-GCM（AES 128位 GCM 模式）、AES-256-CBC、ChaCha20-Poly1305；
  • MAC/PRF：SHA256、SHA384（完整性校验/伪随机函数）。

解读示例：TLS_RSA_WITH_AES_256_CBC_SHA256 = 用 RSA 做密钥交换和认证 + AES-256-CBC 加密 + SHA256 做完整性校验。注意 RSA 密钥交换没有前向安全（私钥泄露后历史流量可解密），现代推荐 ECDHE。

六、安全视角

6.1 TLS 降级攻击

原理：中间人为让客户端用弱加密（如 SSLv3/TLS 1.0），会篡改 ClientHello 把 TLS 版本改低，让双方退回到有漏洞的旧版本协商。

防御：

  • TLS_FALLBACK_SCSV：客户端在降级时打标记，服务器发现标记后拒绝降级；
  • 服务器禁用 TLS 1.0/1.1、SSLv3；
  • 启用 HSTS 头强制浏览器走 HTTPS，避免首次 HTTP 被劫持。

6.2 心脏滴血（Heartbleed，CVE-2014-0160）

原理：OpenSSL 实现 TLS 的 heartbeat 扩展时存在内存越界读取 bug。攻击者发送心跳请求，故意把 payload 长度字段写成 65535，但实际只发 1 字节。服务器会回显「声称长度」的数据，多出来的部分是服务器内存里的随机内容——可能包含私钥、用户密码、Session 等敏感数据。

影响：服务器私钥可能泄露，进而解密历史流量、冒充服务器。修复：升级 OpenSSL 到 1.0.1g 以上，并重置证书和私钥。

6.3 POODLE（CVE-2014-3566）

原理：SSL 3.0 的 CBC 模式填充校验有缺陷，攻击者通过中间人反复请求，利用 padding oracle 逐字节解密 Cookie。只要客户端支持 SSLv3，攻击者就能强制降级到 SSLv3 利用此漏洞。

防御：禁用 SSLv3；使用 TLS 1.2+ 和 AEAD 加密（GCM/ChaCha20）。

6.4 证书伪造

原理：若攻击者能骗 CA 给他签发 www.example.com 的证书（如域名验证漏洞、CA 被攻破、中间 CA 滥用），就能冒充真站做中间人。历史上 DigiNotar、Comodo 等都发生过 CA 被入侵签发伪造证书的事件。

防御：

  • 证书透明度（Certificate Transparency，CT）：所有 CA 签发的证书必须记入公开日志，便于审计发现伪造证书；
  • HPKP（HTTP Public Key Pinning）：固定证书公钥，但已被废弃（误配置会锁死网站）；
  • 监控 CT 日志，发现陌生证书立即报警。

6.5 中间人攻击（MITM）

原理：攻击者夹在客户端和服务器之间，对客户端冒充服务器（出示伪造证书），对服务器冒充客户端，双向解密再加密转发，从而窃听/篡改全部流量。

客户端 ←→ [攻击者] ←→ 服务器
       加密1         加密2
攻击者用伪造证书与客户端通信（加密1），
用真实身份与服务器通信（加密2），
解密后再加密转发，看到所有明文。

防御：

  • 服务器配置好证书链、禁用弱算法；
  • 客户端严格校验证书（不要忽略证书警告！）；
  • 启用 HSTS 防止首次连接被劫持；
  • 关键操作用证书固定（App 端）。

6.6 BEAST、CRIME、BREACH 等压缩/填充攻击

  • BEAST（2011）：针对 TLS 1.0 CBC 模式，攻击者猜测 Cookie。防御：用 TLS 1.1+ 或 RC4（已不推荐）；
  • CRIME（2012）：利用 TLS 压缩 + 已知明文泄露 Cookie。防御：禁用 TLS 压缩；
  • BREACH（2013）：利用 HTTP 响应压缩 + 注入可控明文泄露敏感数据。防御：禁用压缩或加随机填充。

七、安全配置建议

  1. 协议版本：只启用 TLS 1.2 和 TLS 1.3，禁用 SSLv3/TLS 1.0/TLS 1.1；
  2. 加密套件：优先 ECDHE + AES-GCM/ChaCha20-Poly1305，禁用 RC4/DES/CBC；
  3. HSTS：Strict-Transport-Security: max-age=31536000; includeSubDomains; preload；
  4. 证书：使用知名 CA，配置完整证书链（含中间证书），启用 OCSP Stapling；
  5. 禁用压缩：避免 CRIME/BREACH；
  6. 私钥保护：使用 2048 位以上 RSA 或 256 位 ECC，定期轮换，泄露后立即吊销重签；
  7. 监控 CT 日志：发现陌生证书立即调查。
avatar
文章
阅读
粉丝