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

31–40 of 92 posts

Re: Issue with TLS-ALPN-01 Validation Method

#31

Post by tialaramex »

octoberfranklin wrote: post #16
LukeLambert wrote: post #7

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…

Although "TLS can be used for those non-HTTP protocols" the tls-alpn-01 validation can only be used on the authorised ports, which for Let's Encrypt is port 443, aka HTTPS.

Now, Let's Encrypt would technically be allowed to enable this validation on a few other ports, 80 (HTTP), 25 (SMTP) and 22 (SSH) under current Baseline Requirements, but understandably they have no plan to do that.

If you actually want certificate issuance unrelated to web servers you should either hook up a web server explicitly for issuance or use DNS proof of control.

Re: Issue with TLS-ALPN-01 Validation Method

#32

Post by iancarroll »

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…

Certificates have always been sold and priced per year. I highly doubt lifetime changes benefitted certificate authorities, and I’m pretty sure they had it forced upon them by browsers. If anything, it prevents them from collecting 2-3 years of revenue upfront.

Re: Issue with TLS-ALPN-01 Validation Method

#33

Post by rezonant »

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…

Better to be man-in-the-middled for:

- One year instead of two? Yep

- 3 months instead of 1 year? Yep.

- 1 week instead of 3 months? Yep.

The reason certificates have traditionally been so long is because it was a manual process. Using ACME it is possible to expire certificates every hour if you wanted to do that.

Re: Issue with TLS-ALPN-01 Validation Method

#34

Post by labster »

nickf wrote: post #30
jiggawatts wrote: post #29

Earlier quoted context omitted.

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.

That’s because the 1 year certs are too short to be a meaningful difference from LE, so they lose their selling point. So being against the shorter expiration date is just a nefarious plot to make more money, just like supporting it would be. They are so nefarious, they’re nefarious either way! It’s a Certs-22.

Re: Issue with TLS-ALPN-01 Validation Method

#35

Post by phicoh »

rezonant wrote: post #33
jiggawatts wrote: post #29

Earlier quoted context omitted.

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…

Better to be man-in-the-middled for: - One year instead of two? Yep - 3 months instead of 1 year? Yep. - 1 week instead of 3 months? Yep. The reason certificates have traditionally been so long is because it was a manual process. Using ACME it is possible to expire certificates every hour if you wanted to do that.

In the past, revocation was supposed to help cases where the owner of the certificate exposed the private key in one way or another.

Now it seems that revocation is supposed to help the CA covering up mistakes made by the CA.

Maybe we actually need a better CA.

Re: Issue with TLS-ALPN-01 Validation Method

#37

Post by tialaramex »

iancarroll wrote: post #32
jiggawatts wrote: post #29

Earlier quoted context omitted.

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…

Certificates have always been sold and priced per year. I highly doubt lifetime changes benefitted certificate authorities, and I’m pretty sure they had it forced upon them by browsers. If anything, it prevents them from collecting 2-3 years of revenue upfront.

The reduction to 27 months was voted through CA/B (where either CAs or Browsers can effectively veto, like the way Northern Ireland is governed) but only after Ryan suggested Google might just unilaterally impose 90 days if the CAs rejected a reduction.

The reduction to 398 days was imposed by Apple, unilaterally, although in practice the ecosystem went along with it. It actually took a few weeks to get clarity on exactly what Apple intended, they just basically blurted it out at a meeting.

Re: Issue with TLS-ALPN-01 Validation Method

#38

Post by aargh_aargh »

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.

That's what I pondered doing. Do you have any code you can open source? Thanks.

Re: Issue with TLS-ALPN-01 Validation Method

#39

Post by stefan_ »

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…

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.

Re: Issue with TLS-ALPN-01 Validation Method

#40

Post by jabiko »

stefan_ wrote: post #39
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…

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.

Can you give some example of the kind of breakage your experienced?
Post reply on HN