Security Working Group meeting - this Wednesday February 19 - summary results

[Michael Richardson]

Patrick Williams <patrick at stwcx.xyz> wrote:
    >> > 6. (Bruce via email):  BMCWeb Cert valid for 10 years -
    >> > https://lists.ozlabs.org/pipermail/openbmc/2020-February/020488.html 

    >>
    >> Change BMCweb’s default self-signed cert to a maximum of 825 days. 
    >> Recommend 30 days.
    >>
    >> When this is done, if BMCWeb generates a self-signed cert, and it is not
    >> replaced, and the BMC’s time is sane, then browsers that connect to BMCWeb
    >> will start to complain after 30 days.
    >>
    >> The recovery is: The BMC admin should install a valid BMCWeb site identity
    >> cert, then clients can re-connect to the BMC. (This will serve the updated
    >> cert and make the browser happy.)
    >>
    >> The “BMC Admin guide” should talk about installing your own cert.
    >>
    >> See docs here: https://github.com/openbmc/bmcweb/#configuration
    >>
    >> Ass code here: https://github.com/openbmc/bmcweb/blob/91243c3b28b1df66e682f5a3ee96341fdc516b5a/include/ssl_key_handler.hpp#L205
    >>
    >> Will there be a warning for the BMC admin (that the BMCWeb site cert will
    >> expire soon)?  (And don’t rely on a warning from the browser itself.)

    > If I read this correctly, the side-effect of this proposed change is:

    > - If I leave my BMC running for 30 days without it crashing, the
    > certificate it presents will have become expired and no longer
    > valid.

My reading of the code says is that in ensureOpensslKeyPresentAndValid() that
if the certificate is invalid, according to X509_verify_cert() that a new
self-signed certificate will be generated.
So, I agree that if the BMC does not reboot within the self-signed
certificate time, then it will expire, and this will be surprising.

{A system could *easily* get turned on within a group of several hundred, and
nobody gets around to noticing that it wasn't cabled correctly for 30 days
until one gets to the end of the onboarding process and asks why we bought
746 servers, and only onboarded 745 machines.}

So, this is probably rather wrong to limit to 30 days.

a) Only a self-signed certificate that was locally generated should be replaced.
   Replacing an administrator installed certificate because the clock was wrong
   is most likely wrong.

b) As long as we have this logic, we might as well do this check before
   accepting any HTTPS connection, perhaps with a do this at most once a day
   logic.     There is no advantage of expiring a self-signed certificate
   quickly in my opinion.


The concern about the CAB rules about 825 days is probably not important for
several reasons, but if one wants to limit it to that period of time, that's
okay with me.  Changing to 30 days is not a good thing.

1) the browser is going require an exception for the certificate anyway.
   Once the self-signed certificate is pinned in the browser, keeping it for
   as long as possible is better.  Expiring after 30 days makes no sense
   here.

2) it could be that browsers will reject longer-lived certificates when
   validated by a trust anchor, but the exception likely pins whatever comes
   down, period.

3) If a BMC is any kind of vulnerable environment where certificates are
   important, then the BMC needs an automated onboarding system.
   (I have one, and I'm working on code, but it's an unfunded best effort so far)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200224/e87f4a6c/attachment.sig>