SChannel是否支持TLS v1.3密钥更新？对应Win32实现函数是什么

SChannel 没有提供与OpenSSL SSL_key_update() 完全同名的独立API，TLS 1.3的密钥更新能力通过客户端侧InitializeSecurityContext()、服务端侧AcceptSecurityContext() 配合专用标志实现，调用后未生成可发送数据的核心原因是未传入密钥更新专用请求标志。

前置要求 #

• 系统版本为Windows 11 22H2、Windows Server 2022及以上，旧版本Windows的SChannel未实现TLS 1.3支持，无对应密钥更新能力
• 连接已完成完整TLS握手，当前安全上下文有效，无正在进行的重协商/握手流程
• 连接协商的协议版本确认为TLS 1.3，TLS 1.2及更早版本不支持该轻量密钥更新机制，只能通过重协商完成密钥更换

发起密钥更新的正确流程 #

• 初始化输出安全缓冲区（SecBuffer），缓冲区类型设为SECBUFFER_TOKEN，预分配足够空间（建议不小于16KB）
• 调用对应安全上下文函数时，在fContextReq参数的原有标志基础上，根据需要的更新类型追加对应标志：
  • 仅更新本地发送密钥：客户端追加ISC_REQ_KEY_UPDATE，服务端追加ASC_REQ_KEY_UPDATE，等价于OpenSSL中SSL_key_update(SSL_KEY_UPDATE_NOT_REQUESTED)，不会要求对端同步更新密钥
  • 本地更新密钥同时请求对端同步更新：客户端追加ISC_REQ_KEY_UPDATE_REQUEST，服务端追加ASC_REQ_KEY_UPDATE_REQUEST，等价于OpenSSL中SSL_key_update(SSL_KEY_UPDATE_REQUESTED)，发送的KeyUpdate消息会携带对端更新请求标记
• 输入安全缓冲区列表留空，传入已建立的有效安全上下文调用函数
• 若函数返回SEC_E_OK，检查输出SECBUFFER_TOKEN的长度：长度大于0时，缓冲区内容就是标准TLS KeyUpdate协议消息，直接通过现有连接发送给对端即可，无需额外封装
• 消息发送完成后，本地发送密钥会自动切换为新生成的密钥，后续调用EncryptMessage()发送的应用数据会自动使用新密钥加密

对端密钥更新消息的处理 #

无需手动解析收到的KeyUpdate协议消息，只需要把连接收到的所有数据（包括TLS协议层消息）正常传入DecryptMessage()即可，SChannel会自动完成处理：

• 收到无更新请求的普通KeyUpdate消息时，SChannel会自动切换本地接收密钥，后续对端用新密钥加密的应用数据可正常解密，不会向上层返回额外通知
• 收到带更新请求的KeyUpdate消息时，SChannel会自动切换本地接收密钥，在下次调用EncryptMessage()发送应用数据时，会自动拼接生成的KeyUpdate响应消息随应用数据一起返回，直接将返回的所有数据发送给对端即可，无需手动触发响应

常见踩坑说明 #

• 不要参考旧版SChannel重协商文档的流程操作TLS 1.3密钥更新：TLS 1.3已废弃旧的重协商机制，密钥更新是独立的轻量流程，不需要传入重协商所需的额外参数
• 未追加密钥更新专用标志时，调用上下文函数不会生成KeyUpdate消息，会直接返回SEC_E_OK且输出缓冲区为空，这就是无待发送数据的核心原因
• 密钥更新流程不需要重新提供凭证、不需要重新协商连接属性，全程对应用层数据传输无阻塞

内容的提问来源于stack exchange，提问作者Andreas Mueller