On Wed, 28 Nov 2018 22:41:37 +0100 Jakob Bohm via dev-security-policy <[email protected]> wrote:
> I blame those standards for forcing every site to choose between two > unfortunate risks, in this case either the risks prevented by those > "pinning" mechanisms and the risks associated with having only one > certificate. HTTPS Key Pinning (HPKP) is deprecated by Google and is widely considered a failure because it acts as a foot-gun and (more seriously but less likely in practice) enables sites to be held to ransom by bad guys. Mostly though, what I want to focus on is a big hole in your knowledge of what's available today, which I'd argue is likely significant in that probably most certificate Subscribers don't know about it, and that's something the certificate vendors could help to educate them about and/or deliver products to help them 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. No! This system does not need access to private keys. Let us take ACME as our example throughout, though nothing about what I'm describing needs ACME per se, it's simply a properly documented protocol for automation that complies with CA/B rules. The ACME CA expects a CSR, signed with the associated private key, but it does not require that this CSR be created fresh during validation + issuance. A Subscriber can as they wish generate the CSR manually, offline and with full supervision. The CSR is a public document (revealing it does not violate any cryptographic assumptions). It is entirely reasonable to create one CSR when the key pair is minted and replace it only in a scheduled, predictable fashion along with the keys unless a grave security problem occurs with your systems. ACME involves a different private key, possessed by the subscriber/ their agent only for interacting securely with ACME, the ACME client needs this key when renewing, but it doesn't put the TLS certificate key at risk. Certificates are public information by definition. No new risk there. > 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. Again, certificates themselves are public information and this does not require access to the private keys. > 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). This approach, which has been used at some of my past employers, inevitably results in systems where the certificates expire "by mistake". Recriminations and insistence that lessons will be learned follow, and then of course nothing is followed up and the problem recurs. It's a bad idea, a popular one, but still a bad idea. > For example, every BR permitted automated domain validation method > involves a challenge-response interaction with the site owner, who > must not (to prevent rogue issuance) respond to that interaction > except during planned issuance. It is entirely possible and theoretically safe to configure ACME responders entirely passively. You can see this design in several popular third party ACME clients. The reason it's theoretically safe is that ACME's design ensures the validation server (for example Let's Encrypt's Boulder) unavoidably verifies that the validation response is from the correct ACME account holder. So if bad guys request issuance, the auto-responder will present a validation response for the good guy account, which does not match and issuance will not occur. The bad guys will be told their validation failed and they've got the keys wrong. Which of course they can't fix since they've no idea what the right ACME account private key is. For http-01 at least, you can even configure this without the auto-responder having any private knowledge at all. Since this part is just playing back a signature, our basic cryptographic assumptions mean that we can generate the signature offline and then paste it into the auto-responder. At least one popular ACME client offers this behaviour. For a huge outfit like Google or Facebook that can doubtless afford to have an actual "certificate team" this would not be an appropriate measure, but at a smaller business it seems entirely reasonable. > Thus any unscheduled revalidation of domain ownership would, by > necessity, involve contacting the site owner and convincing them this > is not a phishing attempt. See above, this works today for lots of ACME validated domains. > Some ACME protocols may contain specific authenticated ways for the > CA to revalidate out-of-schedule, but this would be outside the norm. Just revalidating, though it seems to be a popular trick for CAs, is not what I had in mind since it wouldn't help here. What needs to happen is a fresh issuance, and ACME can make that pretty trivial as I described. Nick. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
