在 TLS 1.3 (RFC8446) 中，有一个新的 HS 消息“KeyUpdate”，它允许任一对等方请求密钥更新。我们正在尝试查明“KeyUpdate”是否是 TLS 1.3 的必需功能。通过阅读 RFC8446，KeyUpdate 似乎不是一个可以在协商阶段关闭的选项。
我一直在针对 https://tls13.1d.pw（仅限 TLS1.3 的 Web 服务器）测试我们的命令行 TLS 客户端，但当服务器发送“KeyUpdate”记录时，它无法获取页面因为我们使用的 TLS 实现不支持“KeyUpdate”。
有人知道是否需要该功能吗？
此外，使用 TLS 1.3 协议针对现实服务器测试命令行 TLS 客户端的最佳方法是什么？我可以将我们的客户端连接到像 google.com 这样的服务器，但我不知道如何引起足够大的流量以了解 KeyUpdate 在现实生活中是否常用。
非常感谢任何意见！
我遇到这个问题是因为我们在客户端和服务器之间使用 TLS，我的问题是我们是否应该实现密钥更新，以及在什么时间或数据量之后我们应该执行此操作。我们两边都使用OpenSSL，所以服务器端也在我们的控制之下。
我发现一些 TLS 实现实现了自动密钥更新（Red Hat 的幻灯片中提到了 GnuTLS 和 NSS：tls13.pdf）。
所以答案可能是肯定的。另一方可能会请求密钥更新，如果您连接到这样的服务器，它可能会手动触发，也可能会自动触发，具体取决于所使用的 SSL 库。
达到 [AEAD-LIMITS] 时，需要更新密钥。使用 AEAD (AES-GCM) 时，在达到限制之前最多可以加密 2400 万条记录。 请从 RFC 中找到快照，其中对此进行了详细解释
”5.5. 密钥使用限制 明文的数量存在加密限制，可以 在给定的一组密钥下安全地加密。 [AEAD-限制] 在假设下对这些限制进行了分析 底层原语（AES 或 ChaCha20）没有弱点。 实现应该进行密钥更新，如第 4.6.3 节中所述 在达到这些限制之前。 对于 AES-GCM，最多可以有 2^24.5 个全尺寸记录（约 2400 万条） 在给定连接上加密，同时保持安全裕度 大约 2^-57 用于认证加密 (AE) 安全性。为了 ChaCha20/Poly1305，记录序列号将在 已达到安全极限。”