Free, automated SSL certificates for Sandstorm self-hosters
blog.sandstorm.io
blog.sandstorm.io
I'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.