显式密钥确认与接受时机

签名证明某个长期密钥认可了这次交换；它不必证明签名方已经正确计算出本次共享秘密。Finished让一方对完整握手结果做带密钥的确认，因而把“交换记录一致”和“候选秘密可用”接起来。

但它仍是共享密钥认证：若攻击者已经知道确认密钥，就能制造证据。一个公开的正确MAC也不能单独解决身份归属，必须承接已验证的握手上下文。

若双方用同一确认密钥、同一个消息 H(T1)，攻击者可以把客户端发出的MAC原样反射给客户端。客户端若把“验证通过”解释成服务器确认，就接受了自己生成的证据。单独改角色消息、或独立派生角色确认密钥，都会阻断这个特定反射；本单元两处都明确绑定，便于检查各自职责。

检查器用服务器Finished去验证客户端角色的期望输入，得到失败。固定完整T1时，将一个签名字节改变也会改变确认输入；但正确实现应先拒绝无效签名，不能期待Finished代替前面的公钥认证。

双方发完确认消息后，攻击者可以只交付其中一个。客户端可能已进入established，服务端仍在等待。密码协议不能用有限消息强迫双方在同一瞬间知道“对方也知道我已确认”；应用应按各自接受条件解释状态，超时则关闭或重新开始。丢失最后一条确认不等于已经发生密钥泄漏。

本例双方Finished都覆盖同一T1，最终Tf又包含两者。TLS1.3的具体消息次序与覆盖范围不同，尤其客户端Finished的transcript包含此前服务端Finished；不能把教学式直接当作TLS复现。

密钥确认可发现错误的共享值、transcript分歧、身份/角色混淆和部分实现错误。它不保证对方未来保持在线、不保证对方已经持久保存状态，也不保证应用事务已执行。

在确认前发送普通应用数据，会改变协议安全模型。TLS1.3的早期数据有专门的0-RTT和重放限制，不能由普通握手确认结论顺带推出安全。终点检查应记录每个接受事件所依赖的真实接收证据，而不只检查本地能够计算标签。