Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Issue with TLS-ALPN-01 Validation Method

community.letsencrypt.org

Post reply on HN
Print view View original

21–30 of 92 posts

Re: Issue with TLS-ALPN-01 Validation Method

#21

Post by cmeacham98 »

octoberfranklin wrote: post #14
cmeacham98 wrote: post #13

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

Of course it is revocation, it allows you to revoke a certificate before its normal expiration (90 days for LE).

I could make this argument in reverse: "very short lifetimes are functionally equivalent to OCSP Must-Staple, and thus is a form of revocation". Of course, this is ridiculous both ways: being similar or even 'functionally equivalent' does not make two things the same.

Re: Issue with TLS-ALPN-01 Validation Method

#23

Post by vbezhenar »

octoberfranklin wrote: post #15
vbezhenar wrote: post #11

Earlier quoted context omitted.

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.

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

Re: Issue with TLS-ALPN-01 Validation Method

#24

Post by mholt »

nulld3v wrote: post #18
mholt wrote: post #12

Earlier quoted context omitted.

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.

Sounds like a fun project. Assuming you're talking about web servers, did you know Caddy can do that? Simply configure each one to use the same storage backend and Caddy will automatically coordinate management as a cluster, and share the certificate (and OCSP staple) resources.

(And depending on the storage backend, it's no longer a single point of failure. And even if storage is the failure, it's just storage, if it's down your servers will keep running.)

Re: Issue with TLS-ALPN-01 Validation Method

#25

Post by MattPalmer1086 »

octoberfranklin wrote: post #10
mastax wrote: 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…

It limits the time in which a certificate compromise can be exploited. Clients cache CRLs.

Without revocation, a compromised cert remains useful to an attacker for the entire validity period of the cert, it they can MITM you.

With revocation, they must MITM you constantly to prevent you from acquiring the revocation list. This substantially adds to cost and complexity of such an attack, and means that many, if not all clients will be protected.

So it's not perfect, but ask what the world looks like without it.

Re: Issue with TLS-ALPN-01 Validation Method

#26

Post by petecooper »

Ayesh wrote: post #6
mastax wrote: 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.

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.

I hadn't considered this. Am I in the minority by having a legit, monitored email account for my ACME certs?

Re: Issue with TLS-ALPN-01 Validation Method

#29

Post by jiggawatts »

mholt wrote: post #12
mastax wrote: 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…

Certificate expiries are set primarily due to financial interests that have nothing to do with security.

Why do you think the maximum lifetime was reduced from two years to one?

Does it make a lick of difference if you’re man-in-the-middled for just one year instead of two? What kind of argument is that!?

“Oh, they got every active user credential and form that was submitted ages ago, but no worries! This won’t go on for another year! Just months to go now…”

No, obviously the CA cartel just wanted to extract 2x the rent.

The whole thing is just absurd on its face and needs to stop, but there are billions of dollars worth of rent seekers that say…

“No.”

Re: Issue with TLS-ALPN-01 Validation Method

#30

Post by nickf »

jiggawatts wrote: post #29
mholt wrote: post #12

Earlier quoted context omitted.

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…

Certificate expiries are set primarily due to financial interests that have nothing to do with security. Why do you think the maximum lifetime was reduced from two years to one? Does it make a lick of difference if you’re man-in-the-middled for just one year instead of two? What kind of argument is that!? “Oh, they got every active user credential and form that was submitted ages ago, but no worries! This won’t go on…

You might want to double-check that. The CAs (all but two, basically) disagreed with the lifetime reduction and actively voted and argued against it.
Post reply on HN