3 ms·

>To solve this, Sandcats issues certificates valid for only seven days. I'm not sure I'm convinced that the primary motivation for the 7-day certs was users se

>To solve this, Sandcats issues certificates valid for only seven days. I'm not sure I'm convinced that the primary motivation for the 7-day certs was users security.

kentonv 11y ago
What other motivation do you suspect?
- abritishguy 11y ago
  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.
  - kentonv 11y ago
    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.
    - abritishguy 11y ago
      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.
      - savant 11y ago
        You eventually have to roll over keys at least once every N years, so if you are automating it, the length of time doesn't really matter. In this case, they are just limiting the window.
        kentonv 11y ago
        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.
  - ZoF 11y ago
    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.
    - abritishguy 11y ago
      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.
      - kentonv 11y ago
        > 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.)

>To solve this, Sandcats issues certificates valid for only seven days. I'm not sure I'm convinced that the primary motivation for the 7-day certs was users security.

kentonv 11y ago

What other motivation do you suspect?

abritishguy 11y ago
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.
- kentonv 11y ago
  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.
  - abritishguy 11y ago
    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.
    - savant 11y ago
      You eventually have to roll over keys at least once every N years, so if you are automating it, the length of time doesn't really matter. In this case, they are just limiting the window.
      - kentonv 11y ago
        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.
- ZoF 11y ago
  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.
  - abritishguy 11y ago
    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.
    - kentonv 11y ago
      > 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.)