Re: OpenBMC and https Vulnerable issue.

[James Feist <james.feist@linux.intel.com>]

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!
>