3 ms·

> Combine this with exploits into one or more broadly trusted certificate authorities (which surely exist) and it's pretty amazing how much data China would hav

> Combine this with exploits into one or more broadly trusted certificate authorities (which surely exist) and it's pretty amazing how much data China would have been able to obtain. The attacker doesn't even need to compromise a CA. If someone hijacks the IP address of example.com, he could easily get a valid Let's Encrypt certificate for that domain.

gruez 8y ago
this can easily be fixed by having some sort of mandatory waiting period (eg. 7 days) after issuance before a certificate can be considered valid. ct can be used to ensure no backdating occurs
- billylindeman 8y ago
  or dns records validating the ca?
resters 8y ago
Great point. Ideally it would also be possible to track which certificate was used last time and if the certificate has changed, verify somehow whether the change was intentional.
- predakanga 8y ago
  This did exist in the form of HTTP Public Key Pinning (now deprecated). Unfortunately, the mechanism which replaced it (Expect-CT) can only help after the fact - someone would have to notice the extra issuance, and you would have no idea whether your traffic was affected.
tialaramex 8y ago
If there's a CAA record for example.com that doesn't allow Let's Encrypt (CAA tag "letsencrypt.org") then this won't work. Let's Encrypt will check CAA (they will use DNSSEC if your domain has that) and verify that their tag is present before issuing if you have a CAA record. If you're a larger outfit you should pick a trustworthy CA vendor or (two independent vendors according to your risk management profile), and lock CAA to those trusted vendors. You can then agree whatever terms suit your business on top of the Ten Blessed Methods, so as to avoid bad guys stealing your names. For example Facebook has an agreement with their chosen CA that all facebook.com and fb.com issuances get signed off by Facebook's network security people. No "But I'm the head of Asian marketing! I need this immediately" bullshit, it gets a sign off from netsec or it doesn't get issued.

gruez 8y ago

this can easily be fixed by having some sort of mandatory waiting period (eg. 7 days) after issuance before a certificate can be considered valid. ct can be used to ensure no backdating occurs

billylindeman 8y ago
or dns records validating the ca?

resters 8y ago

Great point. Ideally it would also be possible to track which certificate was used last time and if the certificate has changed, verify somehow whether the change was intentional.

predakanga 8y ago
This did exist in the form of HTTP Public Key Pinning (now deprecated). Unfortunately, the mechanism which replaced it (Expect-CT) can only help after the fact - someone would have to notice the extra issuance, and you would have no idea whether your traffic was affected.

tialaramex 8y ago

If there's a CAA record for example.com that doesn't allow Let's Encrypt (CAA tag "letsencrypt.org") then this won't work. Let's Encrypt will check CAA (they will use DNSSEC if your domain has that) and verify that their tag is present before issuing if you have a CAA record. If you're a larger outfit you should pick a trustworthy CA vendor or (two independent vendors according to your risk management profile), and lock CAA to those trusted vendors. You can then agree whatever terms suit your business on top of the Ten Blessed Methods, so as to avoid bad guys stealing your names. For example Facebook has an agreement with their chosen CA that all facebook.com and fb.com issuances get signed off by Facebook's network security people. No "But I'm the head of Asian marketing! I need this immediately" bullshit, it gets a sign off from netsec or it doesn't get issued.