|
|
|
|
|
|
by wyldfire
3722 days ago
|
|
|
From [1]: > In one case, a prominent Dutch CA (DigiNotar) was compromised and the hackers were able to use the CA’s system to issue fake SSL certificates. The certificates were used to impersonate numerous sites in Iran, such as Gmail and Facebook, which enabled the operators of the fake sites to spy on unsuspecting site users. When this happens as the result of malicious actions (unlike the case FB shows here), what actions can the legitimate site operator do to protect their users from this eavesdropping? Presumably you could contact the CA and get the revocation. But even if the CRL's updated, what is the latency to get the browser's trust store sync'd up? And can't state actors just block CRL updates? Do browsers warn users when the CRL can't be updated (after so many attempts or so much time)? [1] http://www.certificate-transparency.org/what-is-ct |
|
|
There's a number of mitigations you can put in place right now. Many of them are not widely supported yet, but will eventually prevent most of the damage an attack could cause. Not all of them apply directly to misissuance, but could be relevant in case of a key compromise or something similar:
- Use HPKP. This allows you to pin your domains to a list of public keys. Most deployments pin to the public key of their CA, as well as a backup CA in case the primary is compromised. It's also possible to pin to your site's public key (along with at least one backup key), although that can go seriously wrong if your key is compromised or lost. HPKP is a trust-on-first-use mechanism, so it will only help protect returning visitors.
- Use a CAA DNS record to forbid any CA other than the ones you're using from issuing certificates for your sites. Some CAs have started supporting CAA, but it's not mandatory yet - hopefully, that'll change! This won't protect you in all scenarios, but depending on how the CA is compromised, a CAA record might be a roadblock. (It would have been in Facebook's case!)
- Use the Must-Staple TLS extension in your certificate. Browsers with Must-Staple support (just Firefox for now) won't accept HTTPS connections unless the web server sends a valid OCSP response as well. This won't help with misissued certificates, but is a good mitigation in case your private key is compromised, essentially fixing the revocation system.
- Future versions of Chrome will support the "Expect-CT" header, which will send a report to an URI if a site fails to deliver CT information. This will ensure that an attack is, at the very least, detectable, even if it doesn't help prevent it.