
Early Impacts of Certificate Transparency - bracewel
https://www.facebook.com/notes/protect-the-graph/early-impacts-of-certificate-transparency/1709731569266987/
======
wyldfire
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](http://www.certificate-transparency.org/what-is-ct)

~~~
pfg
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.

------
colinbartlett
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
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/](https://crt.sh/)

------
jake-low
> [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.

