RE: Security Working Group meeting - this Wednesday February 19 - summary results

[Bruce Mitchell <Bruce_Mitchell@phoenix.com>]

> -----Original Message-----
> From: openbmc [mailto:openbmc-
> bounces+bruce_mitchell=phoenix.com@lists.ozlabs.org] On Behalf Of
> Patrick Williams
> Sent: Friday, February 21, 2020 12:10
> To: Alexander Tereschenko
> Cc: openbmc@lists.ozlabs.org
> Subject: Re: Security Working Group meeting - this Wednesday February
> 19 - summary results
> 
> On Fri, Feb 21, 2020 at 01:19:25PM +0100, Alexander Tereschenko wrote:
> > On 20-Feb-20 17:26, Patrick Williams wrote:
> > > Can we put something into bmcweb to detect its own certificate has
> > > expired and generate a new one?
> >
> > The idea here is to discourage any prolonged use of the default
> self-signed
> > certs at all, as they don't provide full protection from MitM attacks.
> > That's why the 30 days validity period was suggested (compared to
> current 10
> > years) and discussed during the meeting. Adding an auto-regeneration
> feature
> > would be going directly against that idea, so I personally wouldn't
> vote for
> > that.
> 
> To me, if bmcweb is handing out an expired self-signed certificate that is
> a bug.  I don't think we should be so heavy-handed to decide for others
> what "secure" means.  We can certainly propose best practices but we
> should not force specific behavior.
> 
> I'm not suggesting that real certs aren't better than self-signed ones, but
> some people have a well-isolated management network in a data center
> behind locked doors.  They might decide that the likelihood of MitM
> attack there isn't serious enough to devote engineering resources on a
> certificate distribution scheme. (*)
> 
> We should keep in mind that part of the original motivation for this
> project, and what keeps certain companies that don't market general-
> purpose servers involved in it, is that they weren't satisfied with the
> constraints being placed on them by the standard offering in the industry.
> If we become too heavy-handed here, we also lose that advantage.
> 

I do not believe that the BMC's self-generated self-signed certificate should
be beyond what web browsers will accept (or in the near future).  If the customer
wants to install their own self-signed certificate (i.e. not from the BMC) then that
is their issue and can do what they want on  their own self-signed certificate.

> > > I know self-signed certs aren't great, but the minute I have more
> than 6
> > > systems I'm not going to want to follow some "BMC Admin Guide" to
> update
> > > certificates by hand.  So we're effectively forcing everyone to
> develop
> > > some kind of certificate management infrastructure, without
> providing
> > > (or pointing to an existing) implementation.
> > I'd say that in such context, you'd be using one of the configuration
> > management systems (Puppet/Chef/Salt/Ansible/homegrown
> scripts/whatnot)
> > anyway, as that's a standard system administration BKM, so IMHO that's
> a
> > reasonable assumption at the OpenBMC project end that it's not going
> to add
> > any noticeable burden for BMC admins.
> 
> Fair.  But again, others might not feel that is a high enough value
> problem to devote engineering resources to solve.
> 
> (*) Please don't read this as an implication into how my current
>     employer's management network is or is not designed.
> --
> Patrick Williams