A few clarifications below On 30/11/2018 10:48, Nick Lamb wrote: > On Wed, 28 Nov 2018 22:41:37 +0100 > Jakob Bohm via dev-security-policy > <dev-security-policy@lists.mozilla.org> 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. >
Interesting. What is that hole? >> 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. It certainly needs the ability to change private keys (as reusing private keys for new certificates is bad practice and shouldn't be automated). This means that some part of the overall automated system needs the ability to generate fresh keys, sign CSRs, and cause servers to switch to those new keys. And because this discussion entails triggering all that at an out-of-schedule time, having a "CSR pre-generation ceremony" every 24 months (the normal reissue schedule for EV certs) will provide limited ability to handle out-of-schedule certificate replacement (because it is also bad practice to have private keys with a design lifetime of 24 months laying around for 48 months prior to planned expiry). > > 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. > By definition, the strength of public keys, especially TLS RSA signing keys used with PFS suites, involves a security tradeoff between the time that attackers have to break/factor the public key and the slowness of handling TLS connections with current generation standard hardware and software. The current WebPKI/BR tradeoff/compromise is set at 2048 bit keys valid for about 24 months. > >> 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. It requires write access to the private keys, even if the operators might not need to see those keys, many real world systems don't allow granting "install new private key" permission without "see new private key" permission and "choose arbitrary private key" permission. Also, many real world systems don't allow installing a new certificate for an existing key without reinstalling the matching private key, simply because that's the interface. Traditional military encryption systems are built without these limitations, but civilian systems are often not. > >> 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. This is why good CAs send out reminder e-mails in advance. And why one should avoid CAs that use that contact point for infinite spam about new services. > >> 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. The scenario is "Bad guy requests new cert, CA properly challenges good guy at good guy address, good guy responds positively without reference to old good guy CSR, CA issues for bad guy CSR, bad guy grabs new cert from anywhere and matches to bad guy private key, bad guy does actual attack". > > 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. This would only work if the existing CA challenge can be re-used or there is no CA chosen challenge in the protocol. I have yet to look at http-01 as it doesn't fit my own usage scenarios. > > 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. > I was arguing that the general argument was invalid. Obviously revalidation would not be useful for a malformed certificate like the one from D-Trust. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
