[参考译文] CC3235SF：HTTPS 传统重新协商

您好！

我不知道此 特定漏洞、三个漏洞不是此特定重新协商的配置。

 HTTPS 服务器的用途是什么？ 即仅配置？

始终可以选择在主机上托管外部 HTTP 服务器、并具有充分的灵活性和控制能力。

此致、

Shlomi

我们使用 HTTPS 服务器公开多个 REST API (获取器件日志、添加/删除文件、执行 OTA 更新等)。 要清除这些 API，它们是特定于主机应用程序的 API，而不是默认的/API/1/NetApp/[resource] API。

当您说在主机上托管外部 HTTP 服务器时，您是否提到使用 sl_socket 库来设置和托管 HTTP 服务器，而不是 NetApp 库 HTTP 服务器功能？ 如果是、这是否允许配置重新协商策略？

不是、我所说的是在主机上实现的单独 HTTP 服务器、而不是在器件中实现的 HTTP 服务器。

无论如何、让我在内部检查一下我们是否存在 此漏洞的问题。

您好！

当您说它可能容易受到攻击时、您是否实际测试过它？

如果是、请继续并在 https://www.ti.com/technologies/security/report-product-security-vulnerabilities.html 中打开 TT 、以便我们可以在内部驱动它。

此致、

Shlomi

Shlomi、您好！我们已经确认、无论是否进行客户端身份验证、HTTPS 服务器似乎都不会使用 RFC 5746中指定的使用安全重新协商、通过 openssl v 3.0.2。 当我们必须为连接启用传统的不安全协商(SSL_OP_LOW_INSAFLE_UNSAFLE_LEGACY_REGACT_REGACTION)时、遇到了该问题。

然而，我们没有积极地试图利用这一点。

Shlomi、您好、我相信这已经足够了。 感谢您的关注。

我们欢迎你。