CC3235SF: HTTPS Legacy Renegotiation

Hi,

I am not aware of this specific vulnerability and three is no configuration for this specific renegotiation.

What do you use the HTTPS server for? i.e. configuration only?

There is always an option to host an external HTTP server on the host and have full flexibility and control.

Regards,

Shlomi

We're using an HTTPS server to expose several REST APIs (getting device logs, adding/deleting files, performing OTA updates, etc). To be clear these are host application specific APIs and not the default /api/1/netapp/[resource] APIs.

When you say host an external HTTP server on the host, are you referring to using the sl_socket library for setting up and hosting the HTTP server as opposed to the netapp library HTTP server functionality? If so, does this allow for configuring renegotiation policies?

No, I was talking about a separate HTTP server implemented on the host instead of the one implemented in the device.

Anyway, let me check internally if we have something opened on this vulnerability.

Hi,

When you say it may be vulnerable, have you actually tested it?

If so, please go ahead and open a ticket in https://www.ti.com/technologies/security/report-product-security-vulnerabilities.html so we can drive it internally.

Regards,

Shlomi

Hi Shlomi, we have confirmed that both with and without client authentication the HTTPS server does not seem to be using the using secure renegotiation as specified in RFC 5746, via openssl v 3.0.2. The issue was encountered when we had to enable legacy insecure negotiation for the connection (SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION).

We have not actively tried to exploit this, however.

OK, I sent a message internally to check on this topic.

Shlomi

Hi Shlomi, it is my belief that this is sufficient. Thanks you for looking into it.

you are welcomed.