Early Impacts of Certificate Transparency

Early Impacts of Certificate Transparency(facebook.com)

44 points by bracewel 10 years ago | 9 comments

wyldfire 10 years 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

pfg 10 years ago | |

The general consensus is that certificate revocation is essentially broken right now. CRL updates can be blocked (some browsers don't even check) and OCSP defaults to soft-fail in most scenarios, so that's not going to do much against a state actor. IIRC some browsers push their own blacklists for high-profile compromises, but I'm not sure how reliable that is - it could probably be blocked as well.

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.

stanleydrew 10 years ago | |

You can go back in time and turn on public key pinning.

Alternatively, you could turn it on now and protect yourself from reliance on future discovery of safe time travel.

https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning

baby 10 years ago | |

> 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?

There's pretty much nothing you can do except create a new domain and try to tell users to go directly to that one.

prdonahue 10 years ago | |

What actions can a "site operator" take? Not sure what you mean by this. Are you asking what the system administrator of an arbitrary website can do? I'd start with stapling OCSP responses[0] to your TLS handshakes and refreshing them as often as they're updated by the CA.

Note that just having the CAs respond to browser checks (CRL and OCSP) is more or less useless as they're very easy to block (as you suggest) and fail open when blocked. What's needed here (for hard fail) is OCSP Must-Staple; however, this is in the early stages of adoption and it'll be a very long time before it can be relied upon. As Mozilla writes[1]:

> OCSP responders are not yet reliable enough for us to do hard fail. OCSP stapling will help to make hard-fail possible. Must-Staple will be a way to opt into hard-fail.

To answer your question on whether any will warn on soft failure: none that I'm aware of, outside of Firefox declining to provide "EV" treatment in the UI when OCSP fails or is not provided[1].

Note that some CAs, e.g., GlobalSign, are actually removing CRLs entirely from certificates given how useless they have been (and how little modern browsers rely upon). For more nuanced critiques of current revocation options see AGL's writings [2] [3].

The real question here is what the browsers can/should do? Google Chrome has a mechanism called "CRLSets" that they use to push emergency blacklisting of certificates:

From https://dev.chromium.org/Home/chromium-security/crlsets: > CRLSets (background) are primarily a means by which Chrome can quickly block certificates in emergency situations. As a secondary function they can also contain some number of non-emergency revocations. These latter revocations are obtained by crawling CRLs published by CAs.

And Mozilla has their "OneCRL"[4]: > Using OCSP for certificate revocation doesn’t serve users very well. For online revocation checks, either you have a system that fails open or you accept the performance penalty of checks that are more strict (as is the case for EV certificates). OCSP stapling can remove the need for live revocation checks, but currently, only only around 9% of TLS connections use it. OneCRL helps speed up revocation checking by maintaining a centralized list of revoked certificates and pushing it out to browsers.

Not sure what other browsers have done — rarely troubleshoot with anything but Chrome or Firefox.

Hope this helps.

[0] - "RFC 6961: The Transport Layer Security (TLS) Multiple Certificate Status Request Extension" https://tools.ietf.org/html/rfc6961

[1] - "Plan for Improving Revocation Checking in Firefox": https://wiki.mozilla.org/CA:ImprovingRevocation

[2] - "No, don't enable revocation checking (19 Apr 2014)": https://www.imperialviolet.org/2014/04/19/revchecking.html

[3] - "Revocation still doesn't work (29 Apr 2014)": https://www.imperialviolet.org/2014/04/29/revocationagain.ht...

[4] - https://blog.mozilla.org/security/2015/03/03/revoking-interm...

colinbartlett 10 years ago |

Is there an API for certificate transparency logs? I'd love to have a monitoring system that checks if unauthorized certificates are detected for my domains.

pfg 10 years ago | |

The API is essentially a paginated list of certificates. There's no "search by domain" or anything like that. Monitors are expected to continuously get the latest entries and check them according to their rules.

COMODO has a site[1] which allows you to search through a dump of various CT log servers by domain (and various other X.509 fields). It's a great tool, but it doesn't provide the guarantees you get when you scan CT logs directly - you can't be sure the information hasn't been tampered with.

I'm currently working on a side-project where I'm essentially pushing CT log data to a pubic dataset on Google BigQuery, allowing researchers and CT monitors to easily query any CT data. As with COMODO's tool, however, you lose out on the cryptographic assurances a real CT log server provides.

[1]: https://crt.sh/

technion 10 years ago | |

I'll refer you to the monitoring service I put together:

https://ctadvisor.lolware.net/

Meta: I've posted this a few times because it's been a direct response to the question asked. I'd be interested in how to handle future queries without feeling like a spammer.

jake-low 10 years ago |

> [A thank you to Let's Encrypt] Let's Encrypt's issuance in this event was technically correct, and thanks to their commitment to best practices like CT, we were able to discover our internal policy violation and take action to prevent these types of issues in the future. The security team at Let's Encrypt responded quickly and helpfully to our inquiries. Facebook continues to support the Let's Encrypt project and we appreciate their assistance with this investigation.

I continue to be impressed with the Let's Encrypt team's professionalism in their interactions with everyone in the security community. It makes me happy to see post-mortems like this one where everything went as it should have and the issue was resolved without any breech in security. Really reflects well on Let's Encrypt and Facebook's product security team.