OpenBMC and https Vulnerable issue.
James Feist
james.feist at linux.intel.com
Thu Nov 7 08:52:29 AEDT 2019
On 11/6/19 11:31 AM, Bruce Mitchell wrote:
> From my investigations on TLS there seems to be 2 issues that could be corrected with OpenBMC's https:
> 1 Secure Client-Initiated Renegotiation VULNERABLE (NOT ok), DoS threat
This CVE is disputed https://www.cvedetails.com/cve/CVE-2011-1473/ due
to CPU consumption issues that might make it easier to cause a DOS
(which is arguably already not that difficult on a BMC). That being said
the fix is a 1 liner, so I implemented it and it seems to work, but I
need to see if there are any consequences.
https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/26992
> 2 LUCKY13 (CVE-2013-0169), experimental potentially VULNERABLE, uses cipher block chaining (CBC) ciphers with TLS
> and xc023 ECDHE-ECDSA-AES128-SHA256 ECDH 521 AES 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
Based on this https://wiki.crashtest-security.com/prevent-ssl-lucky13,
we are using the recommended ciphers,
https://github.com/openbmc/bmcweb/blob/1f8c7b5d6a679a38b82261060310b876079d0f8b/include/ssl_key_handler.hpp#L330.
And based on this comment from the maintainer of test ssl, no tool can
determine this externally, and it's just a warning:
https://github.com/drwetter/testssl.sh/issues/1011#issuecomment-372953654.
Do you have any suggestions on if there is anything to change for this one?
Thanks
-James
>
> Present standard of practice seems to be to not allow Secure Client-Initiated Renegotiation and to not allow CBC ciphers.
>
> Is this your understanding as well?
>
> Thank you!
>
More information about the openbmc
mailing list