Security Working Group - Wednesday July 22 - results

[Ed Tanous]

On Thu, Jul 23, 2020 at 12:05 PM Michael Richardson <mcr at sandelman.ca> 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?

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

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

> These two are not mutually exclusive.
>
> I hope to clear my plate enough before the end of the year to demonstrate
> this on OpenBMC.

Awesome.  Looking forward to it.

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