BMCWeb policy for HTTPS site identity certificate

[Ed Tanous]

Like I said in the other thread.  The current behavior is a regression
on what the bmcweb behavior was (and was designed to be).

On Sun, Jul 26, 2020 at 1:37 PM Michael Richardson <mcr at sandelman.ca> wrote:
>
>
> Joseph Reynolds <jrey at linux.ibm.com> wrote:
>     > Problem:
>     > BMCWeb apparently treats certificates that are either expired or not valid
>     > until a future date as unusable (investigation needed).  And BMCWeb deletes
>     > unusable certificates.  This can confuse the administrator, especially
>     > considering the BMC's time-of-day clock may not be set as expected.
>
>     > Proposal:
>     > What certificate management policy should BMCWeb use?  Here is an initial
>     > proposal:
>     > 1. certificate is perfectly good - Use the certificate.
>
> okay.
>
>     > 2. certificate is good but expired or not yet valid - Use the certificate and
>     > log a warning.
>
> very good.
>
>     > 3. certificate is missing or bad format or algorithm too old - Use another
>     > certificate or self-generate a certificate (and log that action).
>     > In no case should BMCWeb should delete any certificate.
>
> I think that there is a problem in 3.
>
> "certificate is missing" is pretty much unambiguous.

Unfortunately, this ambiguity comes with the territory.  On first
boot, bmcweb has no certificate, and doesn't know the difference
between "missing" and "was never there".  Regardless, to bring up TLS
it needs _some_ certificate, so the original behavior was that it
generated a new one in all cases where the existing one either didn't
exist or couldn't be used.  This also allows people to start bmcweb up
in "developer" mode, by only sending the binary over, and is useful
for doing A/B compares.
(note, an SSLContext can still be created with a certificate with bad
dates or an unknown certificate chain)

> "bad format" depends a bit upon evolution of libraries.

Today this is defined as the above.  "Can we use this certificate file
for starting up an SSL context?"  If the answer is no, we regenerate.
In theory, the only library we rely on for this is OpenSSL, which I
would hope doesn't have a backward incompatible evolution in this
area.

> In particular, a new version of libssl might support some new algorithm, and
> then should the firmware be rolled back, it will "bad format".

In this hypothetical, you're thinking about a new, non x509
certificate file format?  I vote let's cross that bridge when we get
there, as it seems like there's a lot more discussion that would need
to happen around upgrades and downgrades.  Today the assumption we
make is that x509 certificate reading is backward and forward
compatible since the begining of openbmc, which, to my knowledge, it
is.
In this hypothetical, if x509 instituted a backward incompatible
change AND previous OpenBMC instances were unable to read it, bmcweb
would simply generate a new default certificate.  I don't know if
we've instituted a firmware rollback policy for that case, but I'm
guessing it would be possible (but difficult to maintain).

>
> So I suggest that the certificate+keypair is never deleted, but may be renamed.
> I think that we could have a debate about getting telemetry about bad
> certificates back via HTTP.

We can have a discussion, but I suspect a lot of people would be very
against using unencrypted HTTP for this purpose.

>
> I think that there are some operational considerations relating to
> determining root cause that may trump some security issues relating to
> telling bad actors whether they have succeeded in damaging a certificate.
>
> --
> ]               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    [
>
>
>