Hacker News Reader

Comment by wbond | Hacker News Reader

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.

View on HN

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.

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.

The misissuences have happened over the last several months (since at least December 2019), but it does seem that it was _discovered_ on Friday.

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.

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.

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).

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

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

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

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`.

If you have Must Staple but don't have monitoring in place to detect that your OCSP responses are growing stale before they expire (or worse, you use Apache HTTPD which will happily replace a GOOD OCSP response with a newer BAD one) then you'd still be screwed here when Let's Encrypt revokes certificates.

You need at least effective monitoring and a good OCSP stapling implementation (IIS is supposedly pretty good at this) or else stapling is sadly going to make life worse for you not better.

So in the case that revocation now works, why is there a continued push to shorten certificate lifetimes?

Multiple reasons:

1. Firefox remains the only mainstream browser to support OCSP Must Staple.

2. OCSP Must Staple does not cover all threat models: if an attacker gains the ability to temporarily issue certificates for the victim's domain (rather than obtaining the private key of an existing certificate), they can request a certificate without the OCSP Must Staple extension. A more effective method would be something like the Expect-Staple header[1] (in enforce mode).

3. It allows the ecosystem to move significantly faster. In a world where all certificates expire after 3 months, phasing out insecure hash algorithms (in certificates) would no longer take many years.

4. It encourages regular key rotation (even if it's not enforced)

[1]: https://scotthelme.co.uk/designing-a-new-security-header-exp...

Items 3 and 4 seem like weak arguments. We are still dealing with operating systems from 3+ years ago, so moving below a 1 year certificate length wouldn't buy much agility in terms of new algorithms.

Hash algorithms may not have been the best examples as they require client support.

A better example would be something like Certificate Transparency. Currently, browsers may require Certificate Transparency for certificates issued after a certain date. A malicious or compromised CA may work around this by backdating certificates. This would be less of an issue with shorter certificate lifetimes.

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?

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.

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).

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.

Absence of automation is why the CA death penalty is applied so late due to the consequent disruption.

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...

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/

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.

Blame other CAs for resting on their laurels and allowing LE to steal their marketshare.

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").

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!

>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.

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).

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

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.

Reply on news.ycombinator.com