A requirement of the SSL provider, it doesn't really do much to protect against heartbleed like vulnerabilities - just limits the time an attacker can use the key to 7 days.
The 7-day expiration was definitely something we (Sandstorm) asked for, not Globalsign.
It does simplify recovery after a Heartbleed-like bug, as described in the blog post. Of course it doesn't prevent the bug from happening, but it does greatly simplify recovery afterwards, which is important to me. The security properties are in fact the most exciting thing about short-lived certificates for me personally.
For the sake of transparency, there is another motivation: For a 1-week certificate, we pay 1/52 of what we would have for a 1-year certificate. So if a user installs Sandstorm, gets a certificate, and immediately uninstalls, we don't pay for a full year. More importantly, if a user installs sandstorm several times -- perhaps due to a bug or a misunderstanding -- and gets a new cert every time, we don't take a huge hit. Basically, we get some risk management out of this deal.
It would be nice if you included the financial motivation in the article as well. Makes total sense, and I totally agree that 7 day certs are better (security wise) than 1 year, I just wasn't sure that in the absence of any financial motivation whether it would be worth the effort (having to roll private keys every week) for the limited protection it gives you.
Indeed, we were going to do the auto-renewal regardless, so making it every 7 days didn't really add any work.
Meanwhile I really am paranoid about long-lived keys of any sort, especially if they need to be online as TLS keys must. I wish CAs offered short-lived keys more readily (and web infrastructure supported it); I'd love to enable them for all Sandstorm properties.
Why would that ever be a requirement of the CA? That doesn't make any sense to me at all, genuinely curious if you'd care to share.
I'd also argue that this is a massive help against heartbleed type vulns.
The average pleb(myself included) just patched the vuln and didn't do a thing regarding updating their(now potentially compromised) certs until their regular annual renewal hit.
Given they are managing the certs anyway they can revoke on behalf of the "average pleb", Just like CloudFlare did.
It is debatable how useful revoking is anyway so I agree that this provides more security, I just wasn't sure (until reply from Sandstorm) whether it would be worth the effort of setting up private key rotation.
> they can revoke on behalf of the "average pleb", Just like CloudFlare did.
Yes but the revocation infrastructure was totally overwhelmed by that and it's unclear if many of those revocations ever made it to users' browsers. E.g. Chrome only honors the revocation lists shipped with Chrome updates -- it does not query OCSP -- and browsers that do query OCSP will "fail open" if the servers don't reply (which they often don't).
(It sounds like you recognize this, just stating it for those who might not.)
Probably not a top concern for users, but this does look like it would be really difficult to use with HTTP Public Key Pinning unless Sandstorm were also keeping the pinning TTLs pretty short - which defeats the purpose.
Honestly HPKP terrifies me. If you key is lost or compromised, you "brick" your site. How do you recover from the next Heartbleed?
I think it could make sense to pin an offline key which is in turn used to sign online keys -- it's at least somewhat feasible to build secure, reliable storage for offline keys. But with current tech that would require that your offline key is a CA key, and as a regular user you have no ability to obtain such a certificate.
So basically I don't think HPKP is a good idea, unless you are Google.
I think certificate transparency is the most promising way forward here.
It's true you can really DOS your own site if you don't follow best practices or have catastrophic data loss. Same with HSTS if you ever need to go back to HTTP.
On balance, yours is a solid decision for your company and for typical users. Just pointing out a complication with something new people are starting to use.
I've just started using it with a short TTL and several extra hashes I can fall back on in reserve. Works fine but I'm definitely not 'all in' yet.
Edit: Also, if my understanding is correct you _do_ create an offline 'key' to generate hashes with a backup CSR, though this won't help if your machine (with the backup CSR used to generate a new key & recover from a server compromise) is also compromised.
You can prepare the spare certificate in advance: generate two private keys (preferably with different software on different machines), buy two certs, and only put one of them online. That way, if something goes wrong, you have a known-working certificate you can switch to. It doubles the cost, which may or may not be worth the money.
You're also allowed to pin any certificate in the chain, not just the end-entity cert (https://tools.ietf.org/html/rfc7469#section-2.6), so you have some other options. You can pin some number of CAs that you think are trustworthy CAs: pin not only GlobalSign but a few other major CAs that you'd consider using in the future. That doesn't protect you from all the things HPKP could possibly protect you from, but it does protect you from the DigiNotars and MCS Holdings and TURKTRUSTs of the world.
19 comments
[ 4.2 ms ] story [ 69.4 ms ] threadI'm not sure I'm convinced that the primary motivation for the 7-day certs was users security.
It does simplify recovery after a Heartbleed-like bug, as described in the blog post. Of course it doesn't prevent the bug from happening, but it does greatly simplify recovery afterwards, which is important to me. The security properties are in fact the most exciting thing about short-lived certificates for me personally.
For the sake of transparency, there is another motivation: For a 1-week certificate, we pay 1/52 of what we would have for a 1-year certificate. So if a user installs Sandstorm, gets a certificate, and immediately uninstalls, we don't pay for a full year. More importantly, if a user installs sandstorm several times -- perhaps due to a bug or a misunderstanding -- and gets a new cert every time, we don't take a huge hit. Basically, we get some risk management out of this deal.
In this case, they are just limiting the window.
Meanwhile I really am paranoid about long-lived keys of any sort, especially if they need to be online as TLS keys must. I wish CAs offered short-lived keys more readily (and web infrastructure supported it); I'd love to enable them for all Sandstorm properties.
I'd also argue that this is a massive help against heartbleed type vulns.
The average pleb(myself included) just patched the vuln and didn't do a thing regarding updating their(now potentially compromised) certs until their regular annual renewal hit.
It is debatable how useful revoking is anyway so I agree that this provides more security, I just wasn't sure (until reply from Sandstorm) whether it would be worth the effort of setting up private key rotation.
Yes but the revocation infrastructure was totally overwhelmed by that and it's unclear if many of those revocations ever made it to users' browsers. E.g. Chrome only honors the revocation lists shipped with Chrome updates -- it does not query OCSP -- and browsers that do query OCSP will "fail open" if the servers don't reply (which they often don't).
(It sounds like you recognize this, just stating it for those who might not.)
More info here if anyone's interested in HPKP: https://scotthelme.co.uk/hpkp-http-public-key-pinning/
I think it could make sense to pin an offline key which is in turn used to sign online keys -- it's at least somewhat feasible to build secure, reliable storage for offline keys. But with current tech that would require that your offline key is a CA key, and as a regular user you have no ability to obtain such a certificate.
So basically I don't think HPKP is a good idea, unless you are Google.
I think certificate transparency is the most promising way forward here.
Unfortunately HPKP was adopted by the browsers and TACK has gotten no traction with the vendors, despite being a more flexible system.
On balance, yours is a solid decision for your company and for typical users. Just pointing out a complication with something new people are starting to use.
I've just started using it with a short TTL and several extra hashes I can fall back on in reserve. Works fine but I'm definitely not 'all in' yet.
Edit: Also, if my understanding is correct you _do_ create an offline 'key' to generate hashes with a backup CSR, though this won't help if your machine (with the backup CSR used to generate a new key & recover from a server compromise) is also compromised.
You're also allowed to pin any certificate in the chain, not just the end-entity cert (https://tools.ietf.org/html/rfc7469#section-2.6), so you have some other options. You can pin some number of CAs that you think are trustworthy CAs: pin not only GlobalSign but a few other major CAs that you'd consider using in the future. That doesn't protect you from all the things HPKP could possibly protect you from, but it does protect you from the DigiNotars and MCS Holdings and TURKTRUSTs of the world.