On Wed, Nov 28, 2018 at 4:41 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> On 27/11/2018 00:54, Ryan Sleevi wrote: > > On Mon, Nov 26, 2018 at 12:12 PM Jakob Bohm via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > >> 2. Being critical from a society perspective (e.g. being the contact > >> point for a service to help protect the planet), doesn't mean that > the > >> people running such a service can be expected to be IT superstars > >> capable of dealing with complex IT issues such as unscheduled > >> certificate replacement due to no fault of their own. > >> > > > > That sounds like an operational risk the site (knowingly) took. Solutions > > for automation exist, as do concepts such as "hiring multiple people" > > (having a NOC/SOC). I see nothing to argue that a single person is > somehow > > the risk here. > > > > The number of people in the world who can do this is substantially > smaller than the number of sites that might need them. We must > therefore, by necessity, accept that some such sites will not hire such > people, or worse multiple such people for their own exclusive use. > > Automating certificate deployment (as you often suggest) lowers > operational security, as it necessarily grants read/write access to > the certificate data (including private key) to an automated, online, > unsupervised system. > Respectfully, this isn't accurate. Automated certificate deployment and rotation is a best practice for high-functioning enterprises, and can be done without exposing general read/write access to other systems. I've seen automated certificate rotation implemented in several federal government agencies, and (maybe more importantly) have seen many more agencies let their certificates expire and impact the security of public services due to a lack of automation. Nick already described how the ACME protocol can be automated without exposing the TLS private key, but more generally, organizations can use scoped permissioning to grant individual components only the specific access they need to accomplish their job. As an example, customers of Amazon Web Services can use the IAM permissions framework to establish granular permissions that mitigate the impact of component compromise. Enterprises relying on self-managed infrastructure are free to implement a similar system. For a government example of automated certificate issuance, see https://cloud.gov/docs/services/cdn-route/, which is a FedRAMPed service whose security authorization is signed off on by the Departments of Defense and Homeland Security. Societally important organizations who don't specialize in technology (which is most of them), or for whatever reason can't feasibly automate their certificate operations, should definitely be relying on infrastructure managed by third parties which do specialize in this technology, be it basic site hosting like Squarespace or more sophisticated cloud services. In other words, no organization has an excuse to not be able to rotate a certificate given 5 days' notice. The fact that many large organizations continue to have a problem with this doesn't make it any more excusable. -- Eric > Allowing multiple persons to replace the certificates also lowers > operational security, as it (by definition) grants multiple persons > read/write access to the certificate data. > > Under the current and past CA model, certificate and private key > replacement is a rare (once/2 years) operation that can be done > manually and scheduled weeks in advance, except for unexpected > failures (such as a CA messing up). > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
