Security Working Group - Wednesday July 22 - results

[Michael Richardson]

Ed Tanous <ed at tanous.net> wrote:
    >> Ed Tanous <ed at tanous.net> wrote:
    >> > One thing to note;  At one point, I had talked through how to
    >> > prototype ACME protocol replacement of certificates automatically, so,
    >> > given an ACME server on the network, the BMC could essentially
    >> > automatically provision itself and keep its certs up to date.  If
    >> > someone wanted to run with that, it might reduce some of the pain here
    >> > (and be extremely cool).
    >>
    >> I have running code, but to use ACME, requires some initial trust
    >> relationship.  The manufacturer can do that if they want.

    > Lots of (mostly private) meta layers have this set up already for
    > internal use and add the relevant CA cert to the build.  Also, I think
    > (I could be wrong) the ca-certificates package is included in most
    > builds already so we can handle trust with foreign servers (for things
    > like HTTP event push).  Presumably ACME uses the same trust
    > relationship, or does it have a specific mechanism that's unique?

yes, the ca-certificate package provides CABForum listed keys, but that won't
include my local private-CA, unless I put a custom build in.

ACME requires that the machine that wants a certificate has to prove it's
name somehow.  The tools are https-01 or dns-01 challenge.

https-01 trust requires that the ACME server be able to reach the server (the
BMC) on port-443 to see the challenge.  And do so by DNS name!
The public LetsEncrypt systems need this to be a public name, and there must
be public port-443 connectivity.
But, if you run your own ACME servers, then you can do something different.
(but, you'd have to configure OpenBMC to talk to your servers, so you'd need
a way to tell it do that, so you'd already need admin access...)

If this is done by dns-01 challenge, then the ACME server needs to be able to
do a Dynamic DNS Update.

    >> One can also use draft-ietf-anima-bootstrapping-keyinfra + EST (RFC7030).

    > ... has been added to my nightly reading list.

waiting on a MISREF to become RFC.
https://www.sandelman.ca/SSW/ietf/brski-links/ contains a few videos that
might lighten your load.

    >> > It should be noted, most browsers (in my testing) seem to ignore the
    >> > HTTP date header entirely, so the BMC doesn't even need the correct
    >> > time to set up a proper encryption channel.
    >>
    >> That's very surprising and counter to my experience.
    >> The more likely case is that the OpenBMC has the wrong date.
    >>

    > IIIIInteresting.  Clearly I need to do more testing.  Just to be
    > clear, I'm talking about the HTTP response date:
    > https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Date

    > Not the validity dates in the TLS certificate.  There were a couple
    > versions of bmcweb where the Date field was broken as well as systems
    > with a reset CMOS where the date is incorrectly set to epoch.  In both
    > cases, no browsers threw any kind of warning that I recall, we just
    > happened to notice it on the debug output.

So, the BMC has the wrong date, but the certificate was still valid.
(Browser time >= notBefore, browser time <= notAfter)
I don't expect the browser to care about the date the server thinks it is,
only if the certificate has become invalid.

The proposed code to kill the certificate if it was invalid would have
rendered the certificate unuseable in this context.

--
]               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/20200723/8f9cb76e/attachment-0001.sig>