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

[James Feist <james.feist@linux.intel.com>]

On 2/21/20 12:21 PM, Bruce Mitchell wrote:
> 
> 
>> -----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 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 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.


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