7 ms·

Wonder how many ACME deployments check for revocation, rather than just being on an infrequent cron job? What proportion of affected certificates will be automa

by mastax 5y ago

Wonder how many ACME deployments check for revocation, rather than just being on an infrequent cron job? What proportion of affected certificates will be automatically renewed with no effort? Looking at a few docs, probably not many. In any case there isn't (?) an in-band way to tell the clients that the cert is going to be revoked before it is revoked, so there would be some disruption.

Kesseki 5y ago
There's a plan to make this information available to clients in the future: https://datatracker.ietf.org/doc/draft-aaron-acme-ari/ https://datatracker.ietf.org/doc/draft-aaron-acme-ari/
Ayesh 5y ago
Yeah, further, I doubt many certificates were issued from an account key belonging to a email address that people monitor often, if not at all.
- petecooper 5y ago
  I hadn't considered this. Am I in the minority by having a legit, monitored email account for my ACME certs?
  - kiwijamo 5y ago
    I thought having a proper email account was what most people do. Companies probably use a role-based address e.g. certmaster@myco.com so the email goes to whoever is responsible for it today.
octoberfranklin 5y ago
WebPKI certificate revocation doesn't work anyways. It fails in exactly the case where TLS is needed: MITM. All certificate revocation-checking schemes "fail open" and proceed happily on their way if the MITM blocks their communications with the revocation lists. If you somehow don't have to worry about MITM you don't need anything remotely close to the complexity of TLS. Certificate revocation is mostly security theater.
- vbezhenar 5y ago
  That's issue with buggy clients which should not proceed if CRL is not available. Not issue with PKI per se.
  - octoberfranklin 5y ago
    If they didn't fail open, every time a CA's website went down every single website that used their certificates would go offline as well. You can imagine the DDOS-ransomers licking their lips at this possibility. No, "fail open" has always been the only possible way to implement this. Which is why it's a broken idea from the start.
    - vbezhenar 5y ago
      > If they didn't fail open, every time a CA's website went down every single website that used their certificates would go offline as well. That's not correct. OCSP stamps exist to prevent that kind of a problem.
      - zauguin 5y ago
        OCSP always seemed a bit absurd to me: Instead of sending a OCSP stamp, the CA could also issue a very short lived certificate on demand. It would have the same effect of asserting that the CA currently considers the server to be verified and it doesn't need a separate format.
- cmeacham98 5y ago
  > All certificate revocation-checking schemes "fail open" and proceed happily on their way if the MITM blocks their communications with the revocation lists. Incorrect, firefox implements OCSP Must-Staple and treats a failure there as equivalent to a certificate validation failure. Now if only we could ever get chrome(ium) to implement it...
  - octoberfranklin 5y ago
mholt 5y ago
Caddy does. https://community.letsencrypt.org/t/questions-about-renewing-before-tls-alpn-01-revocations/170449/21?u=mholt https://community.letsencrypt.org/t/questions-about-renewing... And this is one reason why I keep advocating for certificate automation to be built into services/apps, rather than patched on the outside with duck tape. I look forward to the day when cert lifetimes are regularly about as short as OCSP responses. Then we can possibly do away with OCSP entirely.* (* I am of the opinion that revocation is fundamentally broken for Web PKI and it should be phased out in favor of short cert lifetimes. You may disagree and that's fine, but I'm happy to discuss why if you're interested.)
- stefan_ 5y ago
  The way LE and others keep breaking this process and the tools around it is certainly not a great endorsement for having it integrated into a service.
  - jabiko 5y ago
    Can you give some example of the kind of breakage your experienced?
    - kijin 5y ago
      Not OP, but here are some things I've personally experienced: 1. Supposedly more secure challenge types such as TLS-ALPN-01 are far from stable, as the current incident shows. Your cert can be revoked at any time through no fault of your own. After being burned by TLS-SNI-01 the last time, now I refuse to use anything other than plain old HTTP-01 and DNS-01. 2. As soon as the version of the Linux distro I was using (not in my power to change!) reached EOL, certbot suddenly refused to renew, despite the fact that I'd been using more or less the same version of Python and certbot for a number of years and the HTTP-01 challenge requires nothing fancy at all. Why does everyone these days insist on making ops decisions for other people? 3. On a server with existing nginx virtual hosts, certbot injects configuration directives including stuff the nginx team officially recommends against, such as `if` statements. It frequently breaks existing configuration such as rewrites and redirects. After seeing this a number of times, the only conclusion I can make is that certbot has no idea how to manipulate nginx config files. 4. If I have multiple domains pointing at the same application, and remove one of them at a later time, certbot is oblivious and repeatedly fails trying to renew the certificate that now contains an invalid domain. Again, certbot doesn't know how to work with nginx. Maybe 3 and 4 can be improved if ACME was integrated as a proper nginx module instead of certbot trying to change things from the outside. My experience as a whole, however, makes me feel that the LE/certbot teams are rather cavalier about the commitment to stability they need to make if they really want to become an essential part of the world's internet infrastructure. If you want to be paternalistic about managing TLS for people who don't know how to do it, at least try to do it properly!

by mastax 5y ago

Kesseki 5y ago

There's a plan to make this information available to clients in the future: https://datatracker.ietf.org/doc/draft-aaron-acme-ari/ https://datatracker.ietf.org/doc/draft-aaron-acme-ari/

Ayesh 5y ago

Yeah, further, I doubt many certificates were issued from an account key belonging to a email address that people monitor often, if not at all.

petecooper 5y ago
I hadn't considered this. Am I in the minority by having a legit, monitored email account for my ACME certs?
- kiwijamo 5y ago
  I thought having a proper email account was what most people do. Companies probably use a role-based address e.g. certmaster@myco.com so the email goes to whoever is responsible for it today.

octoberfranklin 5y ago

WebPKI certificate revocation doesn't work anyways. It fails in exactly the case where TLS is needed: MITM. All certificate revocation-checking schemes "fail open" and proceed happily on their way if the MITM blocks their communications with the revocation lists. If you somehow don't have to worry about MITM you don't need anything remotely close to the complexity of TLS. Certificate revocation is mostly security theater.

vbezhenar 5y ago
That's issue with buggy clients which should not proceed if CRL is not available. Not issue with PKI per se.
- octoberfranklin 5y ago
  If they didn't fail open, every time a CA's website went down every single website that used their certificates would go offline as well. You can imagine the DDOS-ransomers licking their lips at this possibility. No, "fail open" has always been the only possible way to implement this. Which is why it's a broken idea from the start.
  - vbezhenar 5y ago
    > If they didn't fail open, every time a CA's website went down every single website that used their certificates would go offline as well. That's not correct. OCSP stamps exist to prevent that kind of a problem.
    - zauguin 5y ago
      OCSP always seemed a bit absurd to me: Instead of sending a OCSP stamp, the CA could also issue a very short lived certificate on demand. It would have the same effect of asserting that the CA currently considers the server to be verified and it doesn't need a separate format.
cmeacham98 5y ago
> All certificate revocation-checking schemes "fail open" and proceed happily on their way if the MITM blocks their communications with the revocation lists. Incorrect, firefox implements OCSP Must-Staple and treats a failure there as equivalent to a certificate validation failure. Now if only we could ever get chrome(ium) to implement it...
- octoberfranklin 5y ago

mholt 5y ago

Caddy does. https://community.letsencrypt.org/t/questions-about-renewing-before-tls-alpn-01-revocations/170449/21?u=mholt https://community.letsencrypt.org/t/questions-about-renewing... And this is one reason why I keep advocating for certificate automation to be built into services/apps, rather than patched on the outside with duck tape. I look forward to the day when cert lifetimes are regularly about as short as OCSP responses. Then we can possibly do away with OCSP entirely.* (* I am of the opinion that revocation is fundamentally broken for Web PKI and it should be phased out in favor of short cert lifetimes. You may disagree and that's fine, but I'm happy to discuss why if you're interested.)

stefan_ 5y ago
The way LE and others keep breaking this process and the tools around it is certainly not a great endorsement for having it integrated into a service.
- jabiko 5y ago
  Can you give some example of the kind of breakage your experienced?
  - kijin 5y ago
    Not OP, but here are some things I've personally experienced: 1. Supposedly more secure challenge types such as TLS-ALPN-01 are far from stable, as the current incident shows. Your cert can be revoked at any time through no fault of your own. After being burned by TLS-SNI-01 the last time, now I refuse to use anything other than plain old HTTP-01 and DNS-01. 2. As soon as the version of the Linux distro I was using (not in my power to change!) reached EOL, certbot suddenly refused to renew, despite the fact that I'd been using more or less the same version of Python and certbot for a number of years and the HTTP-01 challenge requires nothing fancy at all. Why does everyone these days insist on making ops decisions for other people? 3. On a server with existing nginx virtual hosts, certbot injects configuration directives including stuff the nginx team officially recommends against, such as `if` statements. It frequently breaks existing configuration such as rewrites and redirects. After seeing this a number of times, the only conclusion I can make is that certbot has no idea how to manipulate nginx config files. 4. If I have multiple domains pointing at the same application, and remove one of them at a later time, certbot is oblivious and repeatedly fails trying to renew the certificate that now contains an invalid domain. Again, certbot doesn't know how to work with nginx. Maybe 3 and 4 can be improved if ACME was integrated as a proper nginx module instead of certbot trying to change things from the outside. My experience as a whole, however, makes me feel that the LE/certbot teams are rather cavalier about the commitment to stability they need to make if they really want to become an essential part of the world's internet infrastructure. If you want to be paternalistic about managing TLS for people who don't know how to do it, at least try to do it properly!