* Security Working Group meeting - this Wednesday February 19 @ 2020-02-17 22:29 Joseph Reynolds 2020-02-19 23:05 ` Security Working Group meeting - this Wednesday February 19 - summary results Joseph Reynolds 0 siblings, 1 reply; 13+ messages in thread From: Joseph Reynolds @ 2020-02-17 22:29 UTC (permalink / raw) To: openbmc This is a reminder of the OpenBMC Security Working Group meeting scheduled for this Wednesday February 19 at 10:00am PDT. We'll discuss current development items, and anything else that comes up. Ratan intends to participate and has requested that we cover the following two items first: (A) service discovery direction, (B) using pam_abl The current topics: 1. (Joseph): Is OpenBMC affected by the Chrome browser’s SameSite cookie changes (https://blog.chromium.org/2020/02/samesite-cookie-changes-in-february.html)? Do we want to enhance BMCWeb (https://github.com/openbmc/bmcweb/blob/master/include/token_authorization_middleware.hpp#L430) to create cookies with SameSite=None; Secure when BMCWEB_INSECURE_DISABLE_XSS_PREVENTION is also used, to allow the BMC to be used by the Chrome browser. Perhaps by default BMCWeb should generate cookies with SameSite=Strict? 2. (Joseph, follow up to agenda item 3 from 2020-02-05): Redfish Privilege updates: https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/28881 and https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/28878 Update Feb 11: See https://redfishforum.com/thread/281/manageraccountcollection-change-allows-account-enumeration clarified the intention to NOT enumerate all accounts (unless you are the admin) 3. (email) FYA. BMC aggregator - includes a security topic. https://lists.ozlabs.org/pipermail/openbmc/2020-February/020433.html 4. (email) FYA - BMC Secure Boot / U-Boot - use dm-verity or alternate? https://lists.ozlabs.org/pipermail/openbmc/2020-February/020452.html 5. Redfish forum question: Direction for channel based restrictions - https://redfishforum.com/thread/279/channel-privilege-support-direction-redfish 6. (Bruce via email): BMCWeb Cert valid for 10 years - https://lists.ozlabs.org/pipermail/openbmc/2020-February/020488.html 7. (Joseph / James / Richard email): Rate limiting, use pam_abl - https://lists.ozlabs.org/pipermail/openbmc/2020-February/020430.html 8. (Joseph via email): New Redfish roles ServiceRep & OemRep - https://lists.ozlabs.org/pipermail/openbmc/2020-February/020540.html 9. (Joseph email): Implement the Redfish PasswordChangeRequired property https://lists.ozlabs.org/pipermail/openbmc/2020-February/020554.html 10. (Joseph email): delete BMCWeb sessions after some kinds of account changes https://lists.ozlabs.org/pipermail/openbmc/2020-February/020555.html Access, agenda, and notes are in the wiki: https://github.com/openbmc/openbmc/wiki/Security-working-group - Joseph ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Security Working Group meeting - this Wednesday February 19 - summary results 2020-02-17 22:29 Security Working Group meeting - this Wednesday February 19 Joseph Reynolds @ 2020-02-19 23:05 ` Joseph Reynolds 2020-02-20 16:26 ` Patrick Williams 2020-03-03 17:56 ` Gunnar Mills 0 siblings, 2 replies; 13+ messages in thread From: Joseph Reynolds @ 2020-02-19 23:05 UTC (permalink / raw) To: openbmc On 2/17/20 4:29 PM, Joseph Reynolds wrote: > This is a reminder of the OpenBMC Security Working Group meeting > scheduled for this Wednesday February 19 at 10:00am PDT. This meeting was held. Only the first 7 items were discussed. The remaining items stay on the list for next time (Wednesday March 4). > > We'll discuss current development items, and anything else that comes up. > > Ratan intends to participate and has requested that we cover the > following two items first: > (A) service discovery direction, (B) using pam_abl > > The current topics: > > 1. (Joseph): Is OpenBMC affected by the Chrome browser’s SameSite > cookie changes > (https://blog.chromium.org/2020/02/samesite-cookie-changes-in-february.html)? > Do we want to enhance BMCWeb > (https://github.com/openbmc/bmcweb/blob/master/include/token_authorization_middleware.hpp#L430) > to create cookies with SameSite=None; Secure when > BMCWEB_INSECURE_DISABLE_XSS_PREVENTION is also used, to allow the BMC > to be used by the Chrome browser. Perhaps by default BMCWeb should > generate cookies with SameSite=Strict? > Joseph will create bmcweb issue for this. > 2. (Joseph, follow up to agenda item 3 from 2020-02-05): Redfish > Privilege updates: > https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/28881 and > https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/28878 Update Feb > 11: See > https://redfishforum.com/thread/281/manageraccountcollection-change-allows-account-enumeration > clarified the intention to NOT enumerate all accounts (unless you are > the admin) Consensus was to leave OpenBMC as-is (only admin can enumerate users) until Redfish releases a new spec. > > 3. (email) FYA. BMC aggregator - includes a security topic. > https://lists.ozlabs.org/pipermail/openbmc/2020-February/020433.html Nancy plans to follow up. > > 4. (email) FYA - BMC Secure Boot / U-Boot - use dm-verity or > alternate? > https://lists.ozlabs.org/pipermail/openbmc/2020-February/020452.html Need BMC threat model to understand what threats dm-verity protects against. Note that integrity protection is a defense in depth against an attacker who can run code on the BMC which writes to the BMC’s file system. Is the BMC filesystem writeable? ANS: It uses read-write overlay filesystem on /etc. Idea: Could discontinue using overlays and use soft links to fs on read-write partition > > 5. Redfish forum question: Direction for channel based restrictions - > https://redfishforum.com/thread/279/channel-privilege-support-direction-redfish Redfish direction is to NOT change Role based on channel, and suggests implementations can offer a different set of accounts based on ingress channel (for example, based on which ethernet device (eth0, eth1, etc) the accessed the BMC). OpenBMC community may have multiple use cases for a feature like this. Either the mgmt network or host may be more secure, and the other is less secure. Idea: expose the list of channels within OpenBMC, and allow Account-Channel associations. For example, an interface to allow “admin2” to access the BMC only from “eth0” or “eth1” but not “eth2”. > > 6. (Bruce via email): BMCWeb Cert valid for 10 years - > https://lists.ozlabs.org/pipermail/openbmc/2020-February/020488.html Change BMCweb’s default self-signed cert to a maximum of 825 days. Recommend 30 days. When this is done, if BMCWeb generates a self-signed cert, and it is not replaced, and the BMC’s time is sane, then browsers that connect to BMCWeb will start to complain after 30 days. The recovery is: The BMC admin should install a valid BMCWeb site identity cert, then clients can re-connect to the BMC. (This will serve the updated cert and make the browser happy.) The “BMC Admin guide” should talk about installing your own cert. See docs here: https://github.com/openbmc/bmcweb/#configuration Ass code here: https://github.com/openbmc/bmcweb/blob/91243c3b28b1df66e682f5a3ee96341fdc516b5a/include/ssl_key_handler.hpp#L205 Will there be a warning for the BMC admin (that the BMCWeb site cert will expire soon)? (And don’t rely on a warning from the browser itself.) > > 7. (Joseph / James / Richard email): Rate limiting, use pam_abl - > https://lists.ozlabs.org/pipermail/openbmc/2020-February/020430.html There was concern about any account lockout mechanism locking out legitimate users; throttling is safer. Next step is to design how this would be used. > > 8. (Joseph via email): New Redfish roles ServiceRep & OemRep - > https://lists.ozlabs.org/pipermail/openbmc/2020-February/020540.html > > 9. (Joseph email): Implement the Redfish PasswordChangeRequired > property > https://lists.ozlabs.org/pipermail/openbmc/2020-February/020554.html > > 10. (Joseph email): delete BMCWeb sessions after some kinds of account > changes > https://lists.ozlabs.org/pipermail/openbmc/2020-February/020555.html > These item (8-10) were not address due to lack of time. They remain for next time. > > Access, agenda, and notes are in the wiki: > > https://github.com/openbmc/openbmc/wiki/Security-working-group > > - Joseph > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Security Working Group meeting - this Wednesday February 19 - summary results 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-24 16:14 ` Michael Richardson 2020-03-03 17:56 ` Gunnar Mills 1 sibling, 2 replies; 13+ messages in thread From: Patrick Williams @ 2020-02-20 16:26 UTC (permalink / raw) To: Joseph Reynolds; +Cc: openbmc [-- Attachment #1: Type: text/plain, Size: 1902 bytes --] On Wed, Feb 19, 2020 at 05:05:09PM -0600, Joseph Reynolds wrote: > On 2/17/20 4:29 PM, Joseph Reynolds wrote: > > 6. (Bruce via email): BMCWeb Cert valid for 10 years - > > https://lists.ozlabs.org/pipermail/openbmc/2020-February/020488.html > > Change BMCweb’s default self-signed cert to a maximum of 825 days. > Recommend 30 days. > > When this is done, if BMCWeb generates a self-signed cert, and it is not > replaced, and the BMC’s time is sane, then browsers that connect to BMCWeb > will start to complain after 30 days. > > The recovery is: The BMC admin should install a valid BMCWeb site identity > cert, then clients can re-connect to the BMC. (This will serve the updated > cert and make the browser happy.) > > The “BMC Admin guide” should talk about installing your own cert. > > See docs here: https://github.com/openbmc/bmcweb/#configuration > > Ass code here: https://github.com/openbmc/bmcweb/blob/91243c3b28b1df66e682f5a3ee96341fdc516b5a/include/ssl_key_handler.hpp#L205 > > Will there be a warning for the BMC admin (that the BMCWeb site cert will > expire soon)? (And don’t rely on a warning from the browser itself.) If I read this correctly, the side-effect of this proposed change is: - If I leave my BMC running for 30 days without it crashing, the certificate it presents will have become expired and no longer valid. Is that true? Can we put something into bmcweb to detect its own certificate has expired and generate a new one? 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. -- Patrick Williams [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Security Working Group meeting - this Wednesday February 19 - summary results 2020-02-20 16:26 ` Patrick Williams @ 2020-02-21 12:19 ` Alexander Tereschenko 2020-02-21 20:10 ` Patrick Williams 2020-02-24 16:14 ` Michael Richardson 1 sibling, 1 reply; 13+ messages in thread From: Alexander Tereschenko @ 2020-02-21 12:19 UTC (permalink / raw) To: openbmc 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. > 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Security Working Group meeting - this Wednesday February 19 - summary results 2020-02-21 12:19 ` Alexander Tereschenko @ 2020-02-21 20:10 ` Patrick Williams 2020-02-21 20:21 ` Bruce Mitchell 0 siblings, 1 reply; 13+ messages in thread From: Patrick Williams @ 2020-02-21 20:10 UTC (permalink / raw) To: Alexander Tereschenko; +Cc: openbmc [-- 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 --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Security Working Group meeting - this Wednesday February 19 - summary results 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 0 siblings, 2 replies; 13+ messages in thread From: Bruce Mitchell @ 2020-02-21 20:21 UTC (permalink / raw) To: Patrick Williams, Alexander Tereschenko; +Cc: openbmc > -----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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Security Working Group meeting - this Wednesday February 19 - summary results 2020-02-21 20:21 ` Bruce Mitchell @ 2020-02-21 20:26 ` Patrick Williams 2020-02-21 20:29 ` James Feist 1 sibling, 0 replies; 13+ messages in thread From: Patrick Williams @ 2020-02-21 20:26 UTC (permalink / raw) To: Bruce Mitchell; +Cc: Alexander Tereschenko, openbmc [-- Attachment #1: Type: text/plain, Size: 1132 bytes --] On Fri, Feb 21, 2020 at 08:21:27PM +0000, Bruce Mitchell wrote: Hi Bruce, > 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 this is in reference to your original concern about the certificate being 800+ days? If so, I agree we should shorten if that is more appropriate from a browser perspective. My only concern is that it appears we're generating the certificate once and if the bmcweb daemon stays up longer than that expiration time, we end up serving out an expired certificate. Unfortunately this isn't something you can even observe until 30 days or so in the future. [ I remember once having a ~40 day bug in a product because someone stored milliseconds in a 32 bit integer. It can be a real pain to debug something that only happens when you don't touch it for a month. ] -- Patrick Williams [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Security Working Group meeting - this Wednesday February 19 - summary results 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 1 sibling, 1 reply; 13+ messages in thread From: James Feist @ 2020-02-21 20:29 UTC (permalink / raw) To: Bruce Mitchell, Patrick Williams, Alexander Tereschenko; +Cc: openbmc 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 > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Security Working Group meeting - this Wednesday February 19 - summary results 2020-02-21 20:29 ` James Feist @ 2020-02-24 16:19 ` Michael Richardson 2020-02-26 11:58 ` Alexander Tereschenko 0 siblings, 1 reply; 13+ messages in thread From: Michael Richardson @ 2020-02-24 16:19 UTC (permalink / raw) To: openbmc [-- Attachment #1: Type: text/plain, Size: 1707 bytes --] 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. > 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. 2) it won't apply to CURL, etc. which might be used to onboard a system automatically. 3) you can't make it configurable, because you can't configure it if you can't connect :-) 825 days (27 months, so 2yr plus some wiggle room) is definitely what they are going to for built-in trust anchors. I'm not sure if this will apply to trust anchors that are loaded into browsers by end users, or if that configuration will somehow be attached to the trust anchor. So, if 825 days is a good default, I'd make it 820 days, and after 410 days, I'd have the self-signed certificate resigned, but not generate a new private key. This allows for mgmt stations to pin the public key of the BMC, ignoring the actual certificate contents. I will try to send a patch to do this. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Security Working Group meeting - this Wednesday February 19 - summary results 2020-02-24 16:19 ` Michael Richardson @ 2020-02-26 11:58 ` Alexander Tereschenko 2020-02-26 13:34 ` Michael Richardson 0 siblings, 1 reply; 13+ messages in thread From: Alexander Tereschenko @ 2020-02-26 11:58 UTC (permalink / raw) To: openbmc > 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Security Working Group meeting - this Wednesday February 19 - summary results 2020-02-26 11:58 ` Alexander Tereschenko @ 2020-02-26 13:34 ` Michael Richardson 0 siblings, 0 replies; 13+ messages in thread From: Michael Richardson @ 2020-02-26 13:34 UTC (permalink / raw) To: Alexander Tereschenko; +Cc: openbmc [-- Attachment #1.1: Type: text/plain, Size: 3755 bytes --] Alexander Tereschenko <aleksandr.v.tereschenko@linux.intel.com> wrote: >> 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. >> mcr> 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. Looking at the mechanism, it would seem that the certificate would be generated upon first power on after the BMC was flashed. If the VAR receives the machine (or the shipping dock receiver), powers it on to make sure it's not a dud, and ships it/puts-it-into-inventory, then the 30-day timer starts then. That's why 30 days is too short. (If the manufacturer can put a proper IDevID into the BMC, that would be better all around) mcr> 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... I believe that the browsers will do this, because the CAFORUM rules would be meaningless of nobody checked :-) > 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. The warning boxes are going away as fast the browser people can convince people like us to do something different. I have sent some emails to some contacts at Chrome and Firefox that deal with CAForum questions, and I hope to get some guidance. > 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. Sure, there are about a hundred other issues that could occur. The admin's out-of-warantee windows-XP desktop can be removed from the equation if the enterprise has some automation, so let's just assume that the other end is secure, okay? > 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 Changing from 10 years to 825 days is probably an acceptable move. Maybe it should be a yocto-build-time configuration option. [-- Attachment #1.2: Signature --] [-- Type: text/plain, Size: 243 bytes --] -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Security Working Group meeting - this Wednesday February 19 - summary results 2020-02-20 16:26 ` Patrick Williams 2020-02-21 12:19 ` Alexander Tereschenko @ 2020-02-24 16:14 ` Michael Richardson 1 sibling, 0 replies; 13+ messages in thread From: Michael Richardson @ 2020-02-24 16:14 UTC (permalink / raw) To: openbmc [-- Attachment #1: Type: text/plain, Size: 3687 bytes --] Patrick Williams <patrick@stwcx.xyz> wrote: >> > 6. (Bruce via email): BMCWeb Cert valid for 10 years - >> > https://lists.ozlabs.org/pipermail/openbmc/2020-February/020488.html >> >> Change BMCweb’s default self-signed cert to a maximum of 825 days. >> Recommend 30 days. >> >> When this is done, if BMCWeb generates a self-signed cert, and it is not >> replaced, and the BMC’s time is sane, then browsers that connect to BMCWeb >> will start to complain after 30 days. >> >> The recovery is: The BMC admin should install a valid BMCWeb site identity >> cert, then clients can re-connect to the BMC. (This will serve the updated >> cert and make the browser happy.) >> >> The “BMC Admin guide” should talk about installing your own cert. >> >> See docs here: https://github.com/openbmc/bmcweb/#configuration >> >> Ass code here: https://github.com/openbmc/bmcweb/blob/91243c3b28b1df66e682f5a3ee96341fdc516b5a/include/ssl_key_handler.hpp#L205 >> >> Will there be a warning for the BMC admin (that the BMCWeb site cert will >> expire soon)? (And don’t rely on a warning from the browser itself.) > If I read this correctly, the side-effect of this proposed change is: > - If I leave my BMC running for 30 days without it crashing, the > certificate it presents will have become expired and no longer > valid. My reading of the code says is that in ensureOpensslKeyPresentAndValid() that if the certificate is invalid, according to X509_verify_cert() that a new self-signed certificate will be generated. So, I agree that if the BMC does not reboot within the self-signed certificate time, then it will expire, and this will be surprising. {A system could *easily* get turned on within a group of several hundred, and nobody gets around to noticing that it wasn't cabled correctly for 30 days until one gets to the end of the onboarding process and asks why we bought 746 servers, and only onboarded 745 machines.} So, this is probably rather wrong to limit to 30 days. a) Only a self-signed certificate that was locally generated should be replaced. Replacing an administrator installed certificate because the clock was wrong is most likely wrong. b) As long as we have this logic, we might as well do this check before accepting any HTTPS connection, perhaps with a do this at most once a day logic. There is no advantage of expiring a self-signed certificate quickly in my opinion. The concern about the CAB rules about 825 days is probably not important for several reasons, but if one wants to limit it to that period of time, that's okay with me. Changing to 30 days is not a good thing. 1) the browser is going require an exception for the certificate anyway. Once the self-signed certificate is pinned in the browser, keeping it for as long as possible is better. Expiring after 30 days makes no sense here. 2) it could be that browsers will reject longer-lived certificates when validated by a trust anchor, but the exception likely pins whatever comes down, period. 3) If a BMC is any kind of vulnerable environment where certificates are important, then the BMC needs an automated onboarding system. (I have one, and I'm working on code, but it's an unfunded best effort so far) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Security Working Group meeting - this Wednesday February 19 - summary results 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-03-03 17:56 ` Gunnar Mills 1 sibling, 0 replies; 13+ messages in thread From: Gunnar Mills @ 2020-03-03 17:56 UTC (permalink / raw) To: Joseph Reynolds, openbmc On 2/19/2020 5:05 PM, Joseph Reynolds wrote: > On 2/17/20 4:29 PM, Joseph Reynolds wrote: > > >> 2. (Joseph, follow up to agenda item 3 from 2020-02-05): Redfish >> Privilege updates: >> https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/28881 and >> https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/28878 Update >> Feb 11: See >> https://redfishforum.com/thread/281/manageraccountcollection-change-allows-account-enumeration >> clarified the intention to NOT enumerate all accounts (unless you are >> the admin) > > Consensus was to leave OpenBMC as-is (only admin can enumerate users) > until Redfish releases a new spec. > This is implemented as Redfish intended, a user without ConfigureUsers privilege will only see their own account here: https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/28881 We don't need to wait for the next Redfish release since Redfish is only further clarifying this in the documentation and implemented in 28881 is how Redfish intended this to work. This fixes 2 validator errors if the validator is run as a ReadOnly or Operator role user. Thx, Gunnar ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2020-03-03 17:56 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 2020-02-26 13:34 ` Michael Richardson 2020-02-24 16:14 ` Michael Richardson 2020-03-03 17:56 ` Gunnar Mills
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.