HTTPS 如何保证安全 讲成 5 个点：它到底保护什么 → 用了哪些密码学 → 握手怎么跑（TLS 1.3）→ 为什么能挡中间人 → 还能怎么加固 & 有何边界。
1) HTTPS 解决了哪些安全目标
- 机密性：窃听者看不懂（对称加密保护数据内容）。
- 完整性：传输中被改动能被发现（AEAD 的认证保证）。
- 身份认证：你连的是“真的那个站”，不是伪装者（服务器证书+CA 信任链）。
- 前向保密（PFS） ：以后即使服务器私钥泄露，历史会话也解不开（临时密钥交换）。
2) 它用了哪些密码学组件
- 非对称密码（认证 & 握手）：服务器用私钥签名，客户端用公钥验签；并用 ECDHE/X25519 等做密钥交换。
- 证书/PKI（证明“公钥属于谁”）：服务器证书由受信任 CA 签发，形成信任链（根 CA → 中间 CA → 服务器证书）。
- 对称加密（AEAD） （保护数据）：如 AES-GCM 或 ChaCha20-Poly1305，同时提供加密+完整性校验。
- KDF/HKDF（密钥派生）：把握手材料“挤汁”出多把不同用途的密钥（握手密钥、应用数据密钥等）。
- 随机数/Nonce/序号：避免重放与密钥/计数器复用。
3) TLS 1.3 握手（简化路径）
-
ClientHello
- 带上支持的套件、曲线（如 X25519）、客户端临时密钥（key share）、以及随机数。
-
ServerHello
- 选择套件与曲线，返回服务器临时密钥。
- 双方用 ECDHE 立刻算出共享秘密（只存在内存里）。
-
证书与认证
- 服务器发 Certificate（含站点证书和中间证书链）与 CertificateVerify（用服务器私钥对握手材料签名）。
- 客户端：验证证书链是否由受信任 CA签发、域名是否匹配 SAN、证书是否过期/吊销；再验签确认“确是该私钥持有者”。
-
派生密钥 & Finished
- 双方用 HKDF 从共享秘密派生握手/应用密钥；互发 Finished（握手摘要的 MAC），确认没被篡改。
-
应用数据加密传输
-
之后的 HTTP 请求/响应都用 AEAD（AES-GCM/ChaCha20-Poly1305）加密；每条记录有自增序号/nonce，带认证标签（tag）。
-
会话恢复/0-RTT：可以用 PSK（预共享密钥）/Session Ticket 快速恢复，但 0-RTT 数据要防重放，通常只用于幂等请求。
4) 为什么能挡“中间人攻击（MitM）”
-
证书链 + 域名校验：中间人没有目标站的私钥与合法证书，伪造证书会在信任链校验中被拒。
-
握手里有签名：服务器用自己的私钥对握手数据签名；中间人无法伪造该签名。
-
前向保密：即便中间人事后拿到服务器私钥，也解不开历史会话（因为密钥来自临时 ECDHE）。
-
协议降级防护：版本与套件协商有“回显验证”，且弱套件在 TLS 1.3 已移除，难以被强制降到不安全算法。
若攻击者能让客户端信任恶意 CA（装入系统/用户信任库），仍可能劫持。这就是为什么生产 App 常配 证书钉扎（Pinning） 与 禁用用户 CA。
5) 常见加固与工程实践
-
HSTS：告知浏览器“此域名只能走 HTTPS”，防止 SSL-strip（HTTP→HTTPS 不能被降回 HTTP）。
-
OCSP Stapling：服务器把“在线证书状态”结果代为夹带，减少失败/隐私泄露。
-
证书钉扎（Pinning） ：在客户端/移动端固化服务器证书或公钥哈希，防“伪造 CA”。
-
强算法优先：TLS 1.3 + X25519 + AES-GCM/ChaCha20-Poly1305；禁用过时算法与压缩。
-
域名隐私：SNI 仍是明文，配合 ECH（Encrypted ClientHello） 可隐藏域名（逐步部署中，需生态支持）。
-
移动端（Android）
- Network Security Config：禁明文、为关键域名配置 pin-set，发布版不信任用户 CA。
- 密钥/证书管理：别把私钥放客户端；仅做服务器认证或双向 TLS（需要再配客户端证书）。
6) HTTPS 的边界与误区
- 端点不安全≠传输安全：服务端被入侵、客户端中木马、XSS/CSRF 都不是 HTTPS 能解决的。
- 混合内容：HTTPS 页面里加载 HTTP 资源会被拦或造成风险。
- 证书有效≠站点可信：钓鱼站也能办证书；还需防社会工程学。
- 信任库很关键：用户或系统装了恶意根证书，可能破坏安全；移动端要限制信任源。
一句话记忆
HTTPS = 证书认证（你连的是谁） + ECDHE 握手（协商会话密钥） + AEAD 加密（机密性+完整性） + PFS（历史不可追溯） ；
再配 HSTS/Pinning 等工程措施，才能“既安全又抗折腾”。
