TLS 与可信连接¶
动机：路径默认不可信¶
不加保护的 HTTP 经过接入点、运营商和中间网络，路径上的对手可能读取密码、修改下载文件或冒充服务器。TLS 在应用协议与传输之间建立受保护通道，目标是认证对端、协商密钥并对后续记录进行机密性与完整性保护。
三类密码学工具¶
- 哈希函数把任意长度输入映射为固定长度摘要，用于完整性结构，但单独哈希不能抵抗主动对手替换摘要。
- 对称加密使用共享密钥，速度快，适合保护大量应用数据。
- 公钥密码使用公钥与私钥，支持数字签名和密钥协商，计算更昂贵。
TLS 把它们组合：证书和签名帮助认证，临时公钥协商得到共享秘密，再派生对称会话密钥，记录层使用 AEAD 同时加密和认证数据。
证书回答什么问题¶
服务器证书把域名、公钥、有效期等信息交给受信任签发者签名。浏览器验证：
- 证书中的主机名是否匹配正在访问的域名。
- 当前时间是否在有效期内。
- 签名链能否连接到本地信任的根证书。
- 密钥用途、算法与策略是否允许。
证书证明“某个受信任体系把这个公钥绑定到该域名”，不证明网站商业信誉或内容无害。根证书信任库和签发流程本身也是安全边界。
TLS 1.3 最小握手¶
省略可选分支后，可形成如下直觉：
客户端 -> 服务器：支持的版本、密码套件、临时密钥份额、随机数
服务器 -> 客户端：选择参数、临时密钥份额、证书、证书签名、握手完成证明
客户端：验证证书与签名，双方从密钥协商结果派生会话密钥
客户端 -> 服务器：握手完成证明
双方：使用认证加密传输应用数据
临时 Diffie–Hellman 类密钥交换使双方在公开信道上导出共享秘密，并提供前向保密：将来服务器长期私钥泄漏，不应直接解开过去已捕获会话。前向保密不保护已经被入侵的实时端点。
TLS 1.3 删除许多旧算法和旧握手分支，以减少错误组合和往返开销。简化协议面本身就是安全改进。
记录层与 AEAD¶
握手后，应用数据被切成记录。AEAD 使用密钥、唯一 nonce 和附加认证数据，输出密文与认证标签。接收方验证标签失败时必须拒绝记录，不能把未经认证的明文交给应用。
nonce 在同一密钥下重复可能严重破坏安全，因此协议规定序号和密钥派生规则。实现者不应自行拼装“加密再随便加哈希”；成熟协议的价值正是把组合方式、错误处理和状态机标准化。
SNI、ALPN 与虚拟主机¶
- SNI 让客户端在握手时说明目标服务器名称，使同一 IP 上的服务器选择正确证书。
- ALPN 协商上层协议，例如 HTTP/1.1 或 HTTP/2。
传统 SNI 可能暴露域名元数据，相关扩展尝试加密更多握手信息。即便应用内容加密，IP、连接时间、数据量等流量特征仍可能可见。
会话恢复与 0-RTT¶
重复连接可用恢复票据减少握手成本。TLS 1.3 的 0-RTT 允许客户端更早发送部分应用数据，但这些早期数据可能被重放。只有天然幂等或具备应用去重的数据才适合 0-RTT；转账、创建订单等操作不能仅因传输更快就忽略重放风险。
最小验证例子¶
检查协商版本、证书链、主机名和验证结果。若不提供正确 SNI，同一 IP 上的服务器可能返回默认证书，导致“直接用 IP 正常连端口但证书错误”。
常见误区与限制¶
- 页面有锁图标不代表业务可信，只表示当前连接满足浏览器的传输安全检查。
- 跳过证书验证会使加密失去身份锚点，中间人可与两端分别加密。
- TLS 终止在反向代理后，代理到后端的链路仍需根据威胁模型保护。
- 证书私钥泄漏、错误日志、弱会话管理和受感染终端都可能绕过安全通道。
自测
为什么只加密、不认证服务器，仍无法阻止中间人？
客户端无法判断协商的密钥属于真实服务器还是攻击者。攻击者可分别与客户端和服务器建立加密连接，在中间解密和重加密。证书验证把密钥与预期域名绑定。