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

[Patrick Williams <patrick@stwcx.xyz>]

[-- Attachment #1: Type: text/plain, Size: 2553 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]