Live data from Hacker News

Issue with TLS-ALPN-01 Validation Method

community.letsencrypt.org

11–20 of 92 posts

Re: Issue with TLS-ALPN-01 Validation Method

#11
post #4

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.

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 the…

That's issue with buggy clients which should not proceed if CRL is not available. Not issue with PKI per se.

Re: Issue with TLS-ALPN-01 Validation Method

#12
post #4

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.

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

Re: Issue with TLS-ALPN-01 Validation Method

#13
post #4

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.

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 the…

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

Re: Issue with TLS-ALPN-01 Validation Method

#14

Earlier quoted context omitted.

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 the…

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

OCSP Must-Staple is just another name for "really short certificate expiration periods"

Must-Staple with a timeout of X seconds is functionally equivalent to a certificate with a validity time of X seconds. In either case you need to go fetch something from the CA every X seconds, or else get booted off the net. The only difference is what you call that thing.

   HN is doing its silly "slow down" nonsense, so I will reply to the reply below by editing here.
To @cmeacham98: I'm not moving the goalposts; all practical revocation schemes fail open. OCSP Must-Staple isn't actually a form of revocation; it is just expiry with a fancy name and lots of extra complexity.

The implementation quirks of one particular CA (LE) are not features of these protocols; they are features of that particular CA's policies.

To @mhils: CAs could easily stand up simple servers that let you ask for the most recent certificate (if any) issued to a given domain and public key.

They don't want to do this because it's a burden. The only reason they run OCSP servers is that they're under pressure from insurers, regulators, and auditors to participate in the whole revocation theater game. Saying "we don't do revocation" would cause people to freak out, and setting up an OCSP server takes effort, but less effort than explaining to the insurers/regulators/auditors that revocation doesn't actually work.

As for CT, the log could simply include an extra (issuer-signed) field which amounts to "I will auto-renew this certificate until $DATE" and omit all the additional certificates issued to that same public key and domain name between the log entry and $DATE. Of course the browser would need to understand this field in order to validate the CT log entry.

I'm not sure super-short expiration is really preferable; it makes the Web even more fragile than it already is. Frankly I think Web PKI is sort of a big mess at this point. Most of it only makes sense when viewed through the lens of "(a) governments will always control DNS for the the two-letter TLDs, (b) Google cannot get all governments to supplicate to Google, therefore (c) we must conjure up an extra layer of entities (the CAs) that can be bullied around by manipulation of browser engine code". This is basically the only reason why DANE (or a modernized revision of it) isn't used.

Re: Issue with TLS-ALPN-01 Validation Method

#15

Earlier quoted context omitted.

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 the…

That's issue with buggy clients which should not proceed if CRL is not available. Not issue with PKI per se.

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.

Re: Issue with TLS-ALPN-01 Validation Method

#16

This is the second security issue with a TLS-based challenge [1]. This was a good reminder to switch to the HTTP challenge for the one remaining server I had that was affected. [1] https://letsencrypt.org/docs/challenge-types/#tls-sni-01

That might work for you, but ALPN needs to exist because there's more to the Internet than just HTTP, and TLS can be used for those non-HTTP protocols. Some of those protocols are more fundamental than HTTP, and making them depend on HTTP would create a circular dependency.

  HN is choking again, so I must reply with edits *sigh*
@tialaramex, you're confusing policies of one CA (LE) with the ALPN protocol. Lets Encrypt isn't the only CA out there. Even so, you can do TLS-ALPN on any port. You can do TLS-ALPN on port 443 without using the HTTP protocol in any way. To ALPN, 443 is just an arbitrary number, like the IP address of Lets Encrypt's server.

> If you actually want certificate issuance unrelated to web servers you should either hook up a web server

Good heavens, no.

Re: Issue with TLS-ALPN-01 Validation Method

#17

Earlier quoted context omitted.

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

OCSP Must-Staple is just another name for "really short certificate expiration periods" Must-Staple with a timeout of X seconds is functionally equivalent to a certificate with a validity time of X seconds. In either case you need to go fetch something from the CA every X seconds, or else get booted off the net. The only difference is what you call that thing. HN is doing its silly "slow down" nonsense, so I will rep…

This is moving the goalposts. You claimed that all certificate revocation methods fail-open, I pointed out that OCSP Must-Staple is a fail-closed revocation method that is implemented in a popular browser.

Regardless, even if "functionally equivalent", there is a practical difference: LE does not allow me to issue a certificate every minute, but does allow the OCSP Must-Staple extension.

Re: Issue with TLS-ALPN-01 Validation Method

#18
post #12
post #4

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.

Caddy does. 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 fun…

I tried solving this a different way for my selfhosted services.

Instead of running certbot on every server, I wrote a custom ACME client that runs on a master server and is responsible for requesting/renewing all certificates that I use. It also automatically deploys each cert to the correct server.

It is a single point of failure but it makes tracking certificate expiry, renewal and revocation so much easier.

Re: Issue with TLS-ALPN-01 Validation Method

#19

Earlier quoted context omitted.

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

OCSP Must-Staple is just another name for "really short certificate expiration periods" Must-Staple with a timeout of X seconds is functionally equivalent to a certificate with a validity time of X seconds. In either case you need to go fetch something from the CA every X seconds, or else get booted off the net. The only difference is what you call that thing. HN is doing its silly "slow down" nonsense, so I will rep…

I absolutely agree that shorter lifetimes are likely preferrable over the additional complexity that comes with OCSP Must-Staple. That being said, one benefit of OCSP Must-Staple is that you don't need to authenticate yourself to get the OCSP response. Another benefit is that Certificate Transparency Logs remain smaller, which in turn also benefits CRLite filter sizes.

Re: Issue with TLS-ALPN-01 Validation Method

#20
post #12
post #4

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.

Caddy does. 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 fun…

RE: revocation broken

Absolutely. Especially with the advent of protocols like ACME it just makes sense.

Here's a nice blogpost from smallstep (not affiliated) on this topic: https://smallstep.com/blog/passive-revocation/

Post reply on HN