Security Working Group meeting - this Wednesday February 19 - summary results
aleksandr.v.tereschenko at linux.intel.com
Wed Feb 26 22:58:38 AEDT 2020
> James Feist <james.feist at linux.intel.com> wrote:
> > I think the original motivation of 10 years was something above the average
> > support cycle of a server, so on first boot the user has something they can
> > use to login to the server with.
> That's not a crazy consideration to me.
James, do you imply that the certificate would be generated during
server manufacturing, not at the first boot at the "end owner's" premise?
If so, that indeed changes the perspective, I personally and I think
everyone in our discussion during the meeting thought of the generation
as happening at the latter moment, not the former.
> > That being said, if the browser wont let you
> > in, that is obviously more important. 30 days seems a bit too strict
> > considering shipping / unpacking times make it likely you'll have an expired
> > certificate upon arrival. But if we can't come to an agreement, we can always
> > make this configurable.
> 1) it would be good to clarify what browsers are really going to do.
Indeed - especially given that the recommendation mentioned  is a
CA-side one (used for _issuing_ certs) and the respective RFC section
for X.509  is unchanged - so I'd expect browsers to continue sticking
to that. Unless, of course, someone decides to go the "let's make it
more secure for people based on that CA/Browser forum recommendation"
way and adds some logic that would do otherwise... However imagine how
would that look like - the browser is at the receiving end (i.e.
browser's user typically has no control over the cert), what does it do
when getting such a cert? Throw a warning like "this server's
certificate is valid for more than two years, beware" or something?
That's bad UX, [very likely] can't be acted upon by the user anyway and
actually FUD - the certificate is perfectly valid.
So if you want my guess, I think browsers won't do a thing about that
and that recommendation will be enforced at the CA level only, so it is
unlikely to affect OpenBMC users at the end of the day.
I was more concerned with the general fact that the self-signed cert we
generate doesn't provide full protection and what _gentle_ nudges could
be used for them to change that. In that context those 30 days looked ok
(don't break anything, but provide additional warning for an admin).
BTW, that MiTM may not only be happening at the network level - e.g.
admin's computer may be compromised and some process there could MitM
the connections without tapping the network infra proper.
All in all, it actually sounds to me like we may as well be not doing
anything here :) If admin's threat model allows for using the
self-generated self-signed cert, early expiration may be worse UX than
today - and if the threat model doesn't allow for that, the cert will be
More information about the openbmc