From: Alexander Tereschenko <aleksandr.v.tereschenko@linux.intel.com>
To: openbmc@lists.ozlabs.org
Subject: Re: Security Working Group meeting - this Wednesday February 19 - summary results
Date: Wed, 26 Feb 2020 12:58:38 +0100 [thread overview]
Message-ID: <817a0984-4928-17c5-d6a5-1f2a5b2ccb1b@linux.intel.com> (raw)
In-Reply-To: <21543.1582561154@localhost>
> James Feist <james.feist@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 [1] is a
CA-side one (used for _issuing_ certs) and the respective RFC section
for X.509 [2] 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
replaced anyway.
[1] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.7.pdf
[2] https://tools.ietf.org/html/rfc5280#section-4.1.2.5
next prev parent reply other threads:[~2020-02-26 11:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-17 22:29 Security Working Group meeting - this Wednesday February 19 Joseph Reynolds
2020-02-19 23:05 ` Security Working Group meeting - this Wednesday February 19 - summary results Joseph Reynolds
2020-02-20 16:26 ` Patrick Williams
2020-02-21 12:19 ` Alexander Tereschenko
2020-02-21 20:10 ` Patrick Williams
2020-02-21 20:21 ` Bruce Mitchell
2020-02-21 20:26 ` Patrick Williams
2020-02-21 20:29 ` James Feist
2020-02-24 16:19 ` Michael Richardson
2020-02-26 11:58 ` Alexander Tereschenko [this message]
2020-02-26 13:34 ` Michael Richardson
2020-02-24 16:14 ` Michael Richardson
2020-03-03 17:56 ` Gunnar Mills
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=817a0984-4928-17c5-d6a5-1f2a5b2ccb1b@linux.intel.com \
--to=aleksandr.v.tereschenko@linux.intel.com \
--cc=openbmc@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.