5 ms·

Emailing users and giving them only 24 hours before their certs are revoked seems very unreasonable. Say you are down and out with a stomach bug or on holiday f

by wbond 7y ago

Emailing users and giving them only 24 hours before their certs are revoked seems very unreasonable. Say you are down and out with a stomach bug or on holiday for a day or two. My understanding is that the 90 day lifetime is largely because revocation can be thwarted. Thus the practical difference between 24 hours and one week is meaningful for server admins, but inconsequential if someone is staging an attack.

thdrdt 7y ago
Well it is very inconvenient, but isn't this the strength of certificates? When something is wrong you can revoke them immediately. Why leave a potential vulnerability open for more than 24 hours?
- wbond 7y ago
  Because revoking them will cause interruption to legitimate users, but doesn’t stop an attack. I’m just starting to think LE is more aimed at large organizations than people running smaller configurations. Which is fine, thankfully we still have traditional CAs. I just hope we don’t devolve into a monoculture of ACME-only SSL.
  - M2Ys4U 7y ago
    ACME-only isn't the problem, it's a Let's Encrypt mono-culture I'm concerned about. We could do with another LE-style service (or two) operated independently (both organisationally and geopolitically).
    - wbond 7y ago
      My point there was more about automation in the cert space could lead to traditional CAs leaving the space, in which case small operators like myself (handful of minor servers) would be forced down the automation route, which isn't necessarily a net positive.
      - wbl 7y ago
        Absence of automation is why the CA death penalty is applied so late due to the consequent disruption.
    - ff317 7y ago
      Yeah I'd love to see one or more additional free ACME issuers that are largely functionally-equivalent to LE, but in a different jurisdiction and under different management, with separate infrastructure, etc. One of the less-obvious reasons: for "serious" usage where you're also stapling OCSP responses, there's a dependency on the cert vendor's OCSP service. You can cache the OCSP outputs to get through short windows of unavailability, but if the vendor's OCSP goes offline for days or suffers some serious incident, it pays to have multiple vendors on-hand. There was such an incident with GlobalSign back in October 2016 (who's otherwise a pretty decent vendor!), so it is a legitimate concern. For "serious" use-cases, you basically need redundant live certs from redundant vendors, and not having a second LE-like option means one of those is still a legacy CA for now...
      - sigio 7y ago
        There's buypass.no / buypass.com ... they are a norwegian CA that also implements ACME. I have only used them for some testing certificates so far, that have not been deployed in the wild, but their server works, the certs are valid in all browsers, and they do upto 6 month valid certs iirc. link: https://community.buypass.com/ https://community.buypass.com/
        folmar 7y ago
        I'm using it in production with no trouble at all - I have one place where it's only possible to add SSL certs through a GUI so longer validity is a dealbreaker.
    - Avamander 7y ago
      Blame other CAs for resting on their laurels and allowing LE to steal their marketshare.
      - M2Ys4U 7y ago
        Oh I'm not shedding any tears for legacy-style CAs. But just because the previous situation was bad doesn't mean that a LE monoculture won't also be bad (for varying definitions of "bad").
  - Santosh83 7y ago
    I think it is more aimed at technically competent users, regardless of organisation size. It is not, as it stands, suitable for direct use by non-technical people who can nevertheless follow step-by-step instructions to purchase and install a certificate from the traditional CAs. Similar 'hold my hand' tooling isn't there yet for LE. Nothing about the protocol itself mandates such short validity periods though I presume? Nevertheless technical people bemoan average users clustering towards centralised web-hosts but forget the reality that hosting a website from your own desktop or a VPS is far from trivial even in 2020!
    - deleted 7y ago
      [deleted]
    - namibj 7y ago
      >Nothing about the protocol itself mandates such short validity periods though I presume? Actually, revocation is broken. Which is a large part of why LE uses 90 days.
  - michaelbuckbee 7y ago
    LetsEncrypt has made the strongest headway in large organizations with thousands of domains like Shopify, Heroku, website builders, etc. as it hits a really sweet spot of usability (controlling the host lets them approve issuance), cost (free) and control (they can trigger mass refreshes).
  - devrand 7y ago
    LE is actually following the rules outlined by the Baseline Requirements. "Traditional CAs" have a tendency to just ignore them when convenient. For example, Sectigo has misissued nearly every certificate since 2002, including ~11 million unexpired ones (as December) and decided to just ignore their duty to revoke misissued certifcates [1]. Should the rules be changed? Maybe. However, when you're giving an immense responsibility to CAs then public trust is paramount. Ignoring agreed upon rules whenever you find it convenient does not inspire much confidence. [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1593776 https://bugzilla.mozilla.org/show_bug.cgi?id=1593776
pfg 7y ago
The Baseline Requirements for publicly-trusted CAs (section 4.9.1.1) require timely revocation of mis-issued certificates - either 24 hours or 5 days depending on the reason. I'm not entirely certain which is applicable here, but I'd assume Let's Encrypt's hands are tied in this case.
- wbond 7y ago
  That is a very useful bit of info. I guess if the mis-issuance happened on Friday evening PT, then fives days is March 4th.
  - thenewnewguy 7y ago
    The misissuences have happened over the last several months (since at least December 2019), but it does seem that it was _discovered_ on Friday.
- djsumdog 7y ago
  I'm glad they decided on the 24 hours, unlike CAs like Comodo which really shouldn't still be a CA after all their fuckups.
  - wowaname 7y ago
    Having too low of a reactionary period can be equally devastating; customers need to have ample time to react to the issue so they don't panic and deploy something buggy without testing beforehand.
tialaramex 7y ago
Not thwarted exactly, but the problem is that the question "Is this certificate still good?" has three possible answers: 1. "Yes, it's still good" 2. "No, it's revoked" 3. "There was a network problem so I'm not sure" Of course bad guys who know you'd get answer 2 can most likely ensure you have answer 3 instead. So the only safe thing to do is treat 2 and 3 the same. If we're not sure this certificate is fine then it's not fine. But in practice answer 3 is common anyway. For some users it may happen essentially all the time. So browser vendors don't like to treat 2 and 3 the same, even though that's the only safe option and that can thwart the effectiveness of revocation. There's definitely further opportunity for improved tooling here. Perhaps this incident will drive it (Let's Encrypt's sheer volume can help in this way).
- willglynn 7y ago
  OCSP is a request/response protocol intended to answer certificate validity questions. It works as you describe, and failures cannot be treated as errors. An attacker who stole a certificate can use it even after revocation by blocking access the relevant OCSP responder. https://tools.ietf.org/html/rfc2560 https://tools.ietf.org/html/rfc2560 OCSP stapling is a mechanism by which a TLS server can make OCSP requests ahead of time and serve the response in-band. TLS clients get a certificate signed by the CA as usual, as well as a recent OCSP response signed by the CA attesting to its continued validity. OCSP stapling allows TLS clients like browsers to know a certificate's revocation status without having to make an extra request, but it changes nothing for an attacker who stole a certificate since they can simply not use it. https://tools.ietf.org/html/rfc6066#section-8 https://tools.ietf.org/html/rfc6066#section-8 OCSP Must Staple is an option that can be included on a certificate stating "I promise to use OCSP stapling". An attacker who stole a "must staple" certificate can either include an OCSP response indicating the certificate is revoked, or they can omit an OCSP response which the TLS client will treat as a hard error. https://tools.ietf.org/html/rfc7633 https://tools.ietf.org/html/rfc7633 In short, RFC 7633 makes certificate revocation work. Web browsers and web servers support this today. If you use Let's Encrypt's `certbot`, pass it `--must-staple`.
  - tialaramex 7y ago
wowaname 7y ago
The problem is LE had five days between reporting the bug and revoking as per Baseline Requirements, but they decided to wait until the last day to send out E-mails. This is not only inconsiderate to customers but also downright reckless to sensitive deployments involving LE.

by wbond 7y ago

thdrdt 7y ago

Well it is very inconvenient, but isn't this the strength of certificates? When something is wrong you can revoke them immediately. Why leave a potential vulnerability open for more than 24 hours?

wbond 7y ago
Because revoking them will cause interruption to legitimate users, but doesn’t stop an attack. I’m just starting to think LE is more aimed at large organizations than people running smaller configurations. Which is fine, thankfully we still have traditional CAs. I just hope we don’t devolve into a monoculture of ACME-only SSL.
- M2Ys4U 7y ago
  ACME-only isn't the problem, it's a Let's Encrypt mono-culture I'm concerned about. We could do with another LE-style service (or two) operated independently (both organisationally and geopolitically).
  - wbond 7y ago
    My point there was more about automation in the cert space could lead to traditional CAs leaving the space, in which case small operators like myself (handful of minor servers) would be forced down the automation route, which isn't necessarily a net positive.
    - wbl 7y ago
      Absence of automation is why the CA death penalty is applied so late due to the consequent disruption.
  - ff317 7y ago
    Yeah I'd love to see one or more additional free ACME issuers that are largely functionally-equivalent to LE, but in a different jurisdiction and under different management, with separate infrastructure, etc. One of the less-obvious reasons: for "serious" usage where you're also stapling OCSP responses, there's a dependency on the cert vendor's OCSP service. You can cache the OCSP outputs to get through short windows of unavailability, but if the vendor's OCSP goes offline for days or suffers some serious incident, it pays to have multiple vendors on-hand. There was such an incident with GlobalSign back in October 2016 (who's otherwise a pretty decent vendor!), so it is a legitimate concern. For "serious" use-cases, you basically need redundant live certs from redundant vendors, and not having a second LE-like option means one of those is still a legacy CA for now...
    - sigio 7y ago
      There's buypass.no / buypass.com ... they are a norwegian CA that also implements ACME. I have only used them for some testing certificates so far, that have not been deployed in the wild, but their server works, the certs are valid in all browsers, and they do upto 6 month valid certs iirc. link: https://community.buypass.com/ https://community.buypass.com/
      - folmar 7y ago
        I'm using it in production with no trouble at all - I have one place where it's only possible to add SSL certs through a GUI so longer validity is a dealbreaker.
  - Avamander 7y ago
    Blame other CAs for resting on their laurels and allowing LE to steal their marketshare.
    - M2Ys4U 7y ago
      Oh I'm not shedding any tears for legacy-style CAs. But just because the previous situation was bad doesn't mean that a LE monoculture won't also be bad (for varying definitions of "bad").
- Santosh83 7y ago
  I think it is more aimed at technically competent users, regardless of organisation size. It is not, as it stands, suitable for direct use by non-technical people who can nevertheless follow step-by-step instructions to purchase and install a certificate from the traditional CAs. Similar 'hold my hand' tooling isn't there yet for LE. Nothing about the protocol itself mandates such short validity periods though I presume? Nevertheless technical people bemoan average users clustering towards centralised web-hosts but forget the reality that hosting a website from your own desktop or a VPS is far from trivial even in 2020!
  - deleted 7y ago
    [deleted]
  - namibj 7y ago
    >Nothing about the protocol itself mandates such short validity periods though I presume? Actually, revocation is broken. Which is a large part of why LE uses 90 days.
- michaelbuckbee 7y ago
  LetsEncrypt has made the strongest headway in large organizations with thousands of domains like Shopify, Heroku, website builders, etc. as it hits a really sweet spot of usability (controlling the host lets them approve issuance), cost (free) and control (they can trigger mass refreshes).
- devrand 7y ago
  LE is actually following the rules outlined by the Baseline Requirements. "Traditional CAs" have a tendency to just ignore them when convenient. For example, Sectigo has misissued nearly every certificate since 2002, including ~11 million unexpired ones (as December) and decided to just ignore their duty to revoke misissued certifcates [1]. Should the rules be changed? Maybe. However, when you're giving an immense responsibility to CAs then public trust is paramount. Ignoring agreed upon rules whenever you find it convenient does not inspire much confidence. [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1593776 https://bugzilla.mozilla.org/show_bug.cgi?id=1593776

pfg 7y ago

The Baseline Requirements for publicly-trusted CAs (section 4.9.1.1) require timely revocation of mis-issued certificates - either 24 hours or 5 days depending on the reason. I'm not entirely certain which is applicable here, but I'd assume Let's Encrypt's hands are tied in this case.

wbond 7y ago
That is a very useful bit of info. I guess if the mis-issuance happened on Friday evening PT, then fives days is March 4th.
- thenewnewguy 7y ago
  The misissuences have happened over the last several months (since at least December 2019), but it does seem that it was _discovered_ on Friday.
djsumdog 7y ago
I'm glad they decided on the 24 hours, unlike CAs like Comodo which really shouldn't still be a CA after all their fuckups.
- wowaname 7y ago
  Having too low of a reactionary period can be equally devastating; customers need to have ample time to react to the issue so they don't panic and deploy something buggy without testing beforehand.

tialaramex 7y ago

Not thwarted exactly, but the problem is that the question "Is this certificate still good?" has three possible answers: 1. "Yes, it's still good" 2. "No, it's revoked" 3. "There was a network problem so I'm not sure" Of course bad guys who know you'd get answer 2 can most likely ensure you have answer 3 instead. So the only safe thing to do is treat 2 and 3 the same. If we're not sure this certificate is fine then it's not fine. But in practice answer 3 is common anyway. For some users it may happen essentially all the time. So browser vendors don't like to treat 2 and 3 the same, even though that's the only safe option and that can thwart the effectiveness of revocation. There's definitely further opportunity for improved tooling here. Perhaps this incident will drive it (Let's Encrypt's sheer volume can help in this way).

willglynn 7y ago
OCSP is a request/response protocol intended to answer certificate validity questions. It works as you describe, and failures cannot be treated as errors. An attacker who stole a certificate can use it even after revocation by blocking access the relevant OCSP responder. https://tools.ietf.org/html/rfc2560 https://tools.ietf.org/html/rfc2560 OCSP stapling is a mechanism by which a TLS server can make OCSP requests ahead of time and serve the response in-band. TLS clients get a certificate signed by the CA as usual, as well as a recent OCSP response signed by the CA attesting to its continued validity. OCSP stapling allows TLS clients like browsers to know a certificate's revocation status without having to make an extra request, but it changes nothing for an attacker who stole a certificate since they can simply not use it. https://tools.ietf.org/html/rfc6066#section-8 https://tools.ietf.org/html/rfc6066#section-8 OCSP Must Staple is an option that can be included on a certificate stating "I promise to use OCSP stapling". An attacker who stole a "must staple" certificate can either include an OCSP response indicating the certificate is revoked, or they can omit an OCSP response which the TLS client will treat as a hard error. https://tools.ietf.org/html/rfc7633 https://tools.ietf.org/html/rfc7633 In short, RFC 7633 makes certificate revocation work. Web browsers and web servers support this today. If you use Let's Encrypt's `certbot`, pass it `--must-staple`.
- tialaramex 7y ago

wowaname 7y ago

The problem is LE had five days between reporting the bug and revoking as per Baseline Requirements, but they decided to wait until the last day to send out E-mails. This is not only inconsiderate to customers but also downright reckless to sensitive deployments involving LE.