BMCWeb policy for HTTPS site identity certificate

[Michael Richardson]

Ed Tanous <ed at tanous.net> wrote:
    >> "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

This is reasonable behaviour, but given that browsers are trying very hard to
make the certificate exception box go away, this does not really help
long-term in my opinion.

Missing means: "ENOFILE", not "Can we use this certificate file for starting
up an SSL Connect".

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

Yes, it does.
For instance, you can't load 1024-bit RSA keys with 1.1.1.
It refuses to start.
Meanwhile, 1.0.x does not have any ECDSA support, and you won't find this out
until the TLS session actually tries to start, at which point, it logs an
obsure message to stderr, and returns an error that most programs don't know
what to do with.
(And the TCP connection just ends)

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

Nope, not about non-X.509.
Algorithms and keysize changes.

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

Until... it isn't.
But, the proposal would have considered a certificate with an invalid date as
being invalid, and generated a new one.

    >> 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 agree.
So, how do you get information at this point?

--
]               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/20200728/005663d2/attachment.sig>