TLS 保护什么？
在通信端点之间协商密钥，保护传输数据的机密性与完整性。通常由客户端验证服务器身份；双向认证另有配置。[1]
089 / 网络与基础设施 / TLS
通道加密了，对面是谁？
TLS · TLS
客户端正在连接支付服务。协议很新、证书也没过期，为什么仍然不能放心发送数据？先检查连接目标，再检查通道保护。
开始探索 ↓6–9 分钟
动手实验 · 场景判断 · 实用检查
动手实验 · 场景判断 · 实用检查
蓝色通道代表传输保护，证书代表身份校验。城堡本身的权限与安全，还需要另行检查。
展开读图提示
读图提示
- 角色与机制
- 两端代表客户端与服务器，通道比喻加密传输，带勾证书提示还要验证通信对象的身份。
- 风险在哪里
- 旁观者比喻窃听者；未正确验证证书时，即使看到加密提示，也可能连到错误的对象。
- 防护与边界
- 使用现代 TLS 并验证证书与主机名。图中内容画得可见是为了讲解；TLS 不保护已失陷的终端或落盘后的数据。
本课任务 / TLS
把加密、服务身份验证与业务可信度分开判断。
- 理解 TLS 1.3 的握手与记录保护
- 测试证书信任、名称和时间
- 识别仿冒域名也能有有效证书
亲手探索 / 不同条件，不同结果
逐项检查，这条连接该不该建立？
调整证书条件，观察验证在哪一步失败。再切换到外观相似的域名：技术验证通过之后，还需要什么判断？
TLS 1.3 身份检查台
加密隧道的另一端，到底是谁？
你想访问的服务是 portal.example。设置实际目的地和证书条件，检查连接能否通过，以及它证明了什么。
尚未运行。先调整实验条件，再查看结果；这里不会连接真实系统。
再试一次：把目的地改为仿冒地址，保留可信且匹配的证书。为什么 TLS 可能通过，而你仍不该交出账户密码？
随手查 / 把理解带回实际工作
理解机制之后，检查这些细节。
实验是简化模型。真实环境需要明确业务规则、验证失败路径，并持续维护配置与证据。
01 / 实用细节
先确认预期的服务名称
应用先确定真正要连接的主机，再将该参考身份与证书标识匹配。不能让不可信页面告诉你“应该信任哪个名字”。[2]
02 / 实用细节
可信签发，不等于名字吻合
03 / 实用细节
密钥协商不是传送密码
TLS 1.3 的握手按选定模式协商共享密钥材料，再派生流量密钥保护记录。教学工作台模拟判断，不执行真实握手或密码运算。[1]
04 / 实用细节
端点仍然能够看到明文
05 / 实用细节
0-RTT 有独立的重放风险
TLS 1.3 的早期数据有不同安全性质，可能被重放。付款、权限修改等有副作用操作不能仅因启用了 TLS 就忽略应用层防重放。[1]
06 / 实用细节
配置和更新也是边界的一部分
使用维护中的 TLS 库与合理的协议配置，覆盖证书续期、错误域名和到期等失败路径。测试必须验证失败时停止，而非静默降级。[3]
从模拟，到验证
找一个获准的环境，实际检查一次。
勾选用于本页自查，不会自动标记整课已学会。练习与清单刷新后重置。
本页已检查 0 / 5 项
客户端连接支付 API 时提示证书主机名不匹配。哪项修复能保留 TLS 对连接目标身份的可靠验证？
能解释原因，再标记学会。
小测结果同步错题本；“已学会”沿用原有本地学习记录。
资料与依据
- IETF RFC 8446 · TLS 1.3 ↗
握手、记录层与 0-RTT 安全边界
- IETF RFC 9525 · 服务身份验证 ↗
参考身份与证书服务名称匹配
- OWASP · Transport Layer Security ↗
证书校验、配置与传输保护边界
本页场景、人物与数据均为教学示例。互动选择不会上传；收藏、已学会与错题沿用当前浏览器本地存储。来源正文核对日期：2026-10-08。