3 ms·

It also ignores the real world as the CA/Browser forum admits they don't understand how certificates are actually used in the real world. They're just breaking

by bigbuppo 10mo ago

It also ignores the real world as the CA/Browser forum admits they don't understand how certificates are actually used in the real world. They're just breaking shit to make the world a worse place.

dijit 10mo ago
everything that uses TLS is publicly routable and runs a web service don’t you know. Well, you could also give every random server you happen to configure an API key with the power change any DNS record it wishes.. what could go wrong? #security
- johncolanduoni 10mo ago
  That’s why the HTTP-01 challenge exists - it’s perfect for public single-server deployments. If you’re doing something substantial enough to need a load balancer, arranging the DNS updates (or centralizing HTTP-01 handling) is going to be the least of your worries. Holding public PKI advancements hostage so that businesses can be lazy about their intranet services is a bad tradeoff for the vast majority of people that rely on public TLS.
  - dijit 10mo ago
    and my IRC servers that don’t have any HTTP daemon (and thus have the port blocked) while being balanced by anycast geo-fenced DNS? There are more things on the internet than web servers. You might say “use DNS-01”; but thats reductive- I’m letting any node control my entire domain (and many of my registrars don’t even allow API access to records- let alone an API key thats limited to a single record; even cloud providers dont have that). I don’t even think mail servers work well with the letsencrypt model unless its a single server for everything without redundancies. I guess nobody runs those anymore though, and, I can see why.
    - cpach 10mo ago
      FWIW, there are ways to use DNS-01 without an API key that can control your entire domain. https://hsm.tunnel53.net/article/dns-for-acme-challenges/ https://hsm.tunnel53.net/article/dns-for-acme-challenges/
    - johncolanduoni 10mo ago
      I've operated things on the web that didn't use HTTP but used public PKI (most recently, WebTransport). But those services are ultimately guests in the house of public PKI, which is mostly attacked by people trying to skim financial information going over public HTTP. Nobody made IRC use public PKI for server verification, and I don't know why we'd except what is now an effectively free CA service to hold itself back for any edge case that piggybacks on it. > and my IRC servers that don’t have any HTTP daemon (and thus have the port blocked) while being balanced by anycast geo-fenced DNS? The certificate you get for the domain can be used for whatever the client accepts it for - the HTTP part only matters for the ACME provider. So you could point port 80 to an ACME daemon and serve only the challenge from there. But this is not necessarily a great solution, depending on what your routing looks like, because you need to serve the same challenge response for any request to that port. > You might say “use DNS-01”; but thats reductive- I’m letting any node control my entire domain (and many of my registrars don’t even allow API access to records- let alone an API key thats limited to a single record; even cloud providers dont have that). The server using the certificate doesn't have to be the one going through the ACME flow, and once you have multiple nodes it's often better that it isn't. It's very rare for even highly sophisticated users of ACME to actually provision one certificate per server.
    - bruce511 10mo ago
      Putting DNS Api keys on every remote install is indeed problematic. The solution however is pretty trivial. For our setup I just made a very small server with a couple of REST endpoints. Each customer gets their own login to our REST server. All they do is ask "get a new cert". The DNS-01 challenge is handled by the REST server, and the cert then supplied to the client install. So the actual customer install never sees our DNS API keys.
- nickf 10mo ago
  If it doesn’t run a web service, or isn’t publicly routable - why do you need it to work on billions of users browsers and devices around the world?
  - dijit 10mo ago
    Are we pretending browsers aren’t a universal app delivery platform, fueling internal corporate tools and hobby projects alike? Or that TLS and HTTPS are unrelated, when HTTPS is just HTTP over TLS; and TLS secures far more, from APIs and email to VPNs, IoT, and non-browser endpoints? Both are bunk; take your pick. Or opt for door three: Ignore how CA/B Forum’s relentless ratcheting burdens ops into forking browsers, hacking root stores, or splintering ecosystems with exploitable kludges (they won’t: they’ll go back to “this cert is invalid, proceed anyway?” for all internal users). Nothing screams “sound security” like 45-day cert churn for systems outside the public browser fray. And hey, remember back in the day when all the SMTP submission servers just blindly accepted any certificate they were handed because doing domain validation broke email… yeah Inspired.
    - johncolanduoni 10mo ago
      > Or opt for door three: Ignore how CA/B Forum’s relentless ratcheting burdens ops into forking browsers, hacking root stores, or splintering ecosystems with exploitable kludges (they won’t: they’ll go back to “this cert is invalid, proceed anyway?” for all internal users). It does none of these. Putting more elbow grease into your ACME setup with existing, open source tools solves this for basically any use case where you control the server. If you're operating something from a vendor you may be screwed, but if I had a vote I'd vote that we shouldn't ossify public PKI forever to support the business models of vendors that don't like to update things (and refuse to provide an API to set the server certificate programmatically, which also solves this problem). > Nothing screams “sound security” like 45-day cert churn for systems outside the public browser fray. Yes, but unironically. If rotating certs is a once a year process and the guy who knew how to do it has since quit, how quickly is your org going to rotate those certs in the event of a compromise? Most likely some random service everyone forgot about will still be using the compromised certificate until it expires. > And hey, remember back in the day when all the SMTP submission servers just blindly accepted any certificate they were handed because doing domain validation broke email… yeah Everyone likes to meme on this, but TLS without verification is actually substantially stronger than nothing for server-to-server SMTP (though verification is even better). It's much easier to snoop on a TCP connection than it is to MITM it when you're communicating between two different datacenters (unlike a coffeeshop). And most mail is between major providers in practice, so they were able to negotiate how to establish trust amongst themselves and protect the vast majority of email from MITM too.
johncolanduoni 10mo ago
They are calibrated for organizations/users that have higher consequences for mis-issuance and revocation delay than someone’s holiday blog, but I don’t think they’re behaving selfishly or irrationally in this instance. There are meaningful security benefits to users if certificate lifetimes are short and revocation lists are short, and for the most part public PKI is only as strong as the weakest CA. OCSP (with stapling) was an attempt to get these benefits with less disruption, but it failed for the same reason this change is painful: server operators don’t want to have to configure anything for any reason ever.
- alwillis 10mo ago
  > OCSP failed for the same reason this change is painful: server operators don’t want to have to configure anything for any reason ever. OCSP is going end-of-life because it makes it too easy to track users. From Lets Encrypt[1]: We ended support for OCSP primarily because it represents a considerable risk to privacy on the Internet. When someone visits a website using a browser or other software that checks for certificate revocation via OCSP, the Certificate Authority (CA) operating the OCSP responder immediately becomes aware of which website is being visited from that visitor’s particular IP address. Even when a CA intentionally does not retain this information, as is the case with Let’s Encrypt, it could accidentally be retained or CAs could be legally compelled to collect it. CRLs do not have this issue. [1]: https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-end-of-life https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-...
  - johncolanduoni 10mo ago
    Client-side OCSP makes it too easy to track users. OCSP stapling largely solves that (plus the latency/fail-open issues) by having the server staple a recent OCSP response to the certificate during TLS negotiation. If OCSP stapling had succeeded, the privacy issues would have mostly disappeared (you could track that a server was serving traffic for a domain, but not the users).
    - tatersolid 10mo ago
the8472 10mo ago
> They're just breaking shit to make the world a worse place. Well, it's the people who want to MITM that started it, a lot of effort has been spent on a red queen's race ever since. If you humans would coordinate to stay in high-trust equilibria instead of slipping into lower ones you could avoid spending a lot on security.
deleted 10mo ago
[deleted]

It also ignores the real world as the CA/Browser forum admits they don't understand how certificates are actually used in the real world. They're just breaking shit to make the world a worse place.

dijit 10mo ago

everything that uses TLS is publicly routable and runs a web service don’t you know. Well, you could also give every random server you happen to configure an API key with the power change any DNS record it wishes.. what could go wrong? #security

johncolanduoni 10mo ago
That’s why the HTTP-01 challenge exists - it’s perfect for public single-server deployments. If you’re doing something substantial enough to need a load balancer, arranging the DNS updates (or centralizing HTTP-01 handling) is going to be the least of your worries. Holding public PKI advancements hostage so that businesses can be lazy about their intranet services is a bad tradeoff for the vast majority of people that rely on public TLS.
- dijit 10mo ago
  and my IRC servers that don’t have any HTTP daemon (and thus have the port blocked) while being balanced by anycast geo-fenced DNS? There are more things on the internet than web servers. You might say “use DNS-01”; but thats reductive- I’m letting any node control my entire domain (and many of my registrars don’t even allow API access to records- let alone an API key thats limited to a single record; even cloud providers dont have that). I don’t even think mail servers work well with the letsencrypt model unless its a single server for everything without redundancies. I guess nobody runs those anymore though, and, I can see why.
  - cpach 10mo ago
    FWIW, there are ways to use DNS-01 without an API key that can control your entire domain. https://hsm.tunnel53.net/article/dns-for-acme-challenges/ https://hsm.tunnel53.net/article/dns-for-acme-challenges/
  - johncolanduoni 10mo ago
    I've operated things on the web that didn't use HTTP but used public PKI (most recently, WebTransport). But those services are ultimately guests in the house of public PKI, which is mostly attacked by people trying to skim financial information going over public HTTP. Nobody made IRC use public PKI for server verification, and I don't know why we'd except what is now an effectively free CA service to hold itself back for any edge case that piggybacks on it. > and my IRC servers that don’t have any HTTP daemon (and thus have the port blocked) while being balanced by anycast geo-fenced DNS? The certificate you get for the domain can be used for whatever the client accepts it for - the HTTP part only matters for the ACME provider. So you could point port 80 to an ACME daemon and serve only the challenge from there. But this is not necessarily a great solution, depending on what your routing looks like, because you need to serve the same challenge response for any request to that port. > You might say “use DNS-01”; but thats reductive- I’m letting any node control my entire domain (and many of my registrars don’t even allow API access to records- let alone an API key thats limited to a single record; even cloud providers dont have that). The server using the certificate doesn't have to be the one going through the ACME flow, and once you have multiple nodes it's often better that it isn't. It's very rare for even highly sophisticated users of ACME to actually provision one certificate per server.
  - bruce511 10mo ago
    Putting DNS Api keys on every remote install is indeed problematic. The solution however is pretty trivial. For our setup I just made a very small server with a couple of REST endpoints. Each customer gets their own login to our REST server. All they do is ask "get a new cert". The DNS-01 challenge is handled by the REST server, and the cert then supplied to the client install. So the actual customer install never sees our DNS API keys.
nickf 10mo ago
If it doesn’t run a web service, or isn’t publicly routable - why do you need it to work on billions of users browsers and devices around the world?
- dijit 10mo ago
  Are we pretending browsers aren’t a universal app delivery platform, fueling internal corporate tools and hobby projects alike? Or that TLS and HTTPS are unrelated, when HTTPS is just HTTP over TLS; and TLS secures far more, from APIs and email to VPNs, IoT, and non-browser endpoints? Both are bunk; take your pick. Or opt for door three: Ignore how CA/B Forum’s relentless ratcheting burdens ops into forking browsers, hacking root stores, or splintering ecosystems with exploitable kludges (they won’t: they’ll go back to “this cert is invalid, proceed anyway?” for all internal users). Nothing screams “sound security” like 45-day cert churn for systems outside the public browser fray. And hey, remember back in the day when all the SMTP submission servers just blindly accepted any certificate they were handed because doing domain validation broke email… yeah Inspired.
  - johncolanduoni 10mo ago
    > Or opt for door three: Ignore how CA/B Forum’s relentless ratcheting burdens ops into forking browsers, hacking root stores, or splintering ecosystems with exploitable kludges (they won’t: they’ll go back to “this cert is invalid, proceed anyway?” for all internal users). It does none of these. Putting more elbow grease into your ACME setup with existing, open source tools solves this for basically any use case where you control the server. If you're operating something from a vendor you may be screwed, but if I had a vote I'd vote that we shouldn't ossify public PKI forever to support the business models of vendors that don't like to update things (and refuse to provide an API to set the server certificate programmatically, which also solves this problem). > Nothing screams “sound security” like 45-day cert churn for systems outside the public browser fray. Yes, but unironically. If rotating certs is a once a year process and the guy who knew how to do it has since quit, how quickly is your org going to rotate those certs in the event of a compromise? Most likely some random service everyone forgot about will still be using the compromised certificate until it expires. > And hey, remember back in the day when all the SMTP submission servers just blindly accepted any certificate they were handed because doing domain validation broke email… yeah Everyone likes to meme on this, but TLS without verification is actually substantially stronger than nothing for server-to-server SMTP (though verification is even better). It's much easier to snoop on a TCP connection than it is to MITM it when you're communicating between two different datacenters (unlike a coffeeshop). And most mail is between major providers in practice, so they were able to negotiate how to establish trust amongst themselves and protect the vast majority of email from MITM too.

johncolanduoni 10mo ago

They are calibrated for organizations/users that have higher consequences for mis-issuance and revocation delay than someone’s holiday blog, but I don’t think they’re behaving selfishly or irrationally in this instance. There are meaningful security benefits to users if certificate lifetimes are short and revocation lists are short, and for the most part public PKI is only as strong as the weakest CA. OCSP (with stapling) was an attempt to get these benefits with less disruption, but it failed for the same reason this change is painful: server operators don’t want to have to configure anything for any reason ever.

alwillis 10mo ago
> OCSP failed for the same reason this change is painful: server operators don’t want to have to configure anything for any reason ever. OCSP is going end-of-life because it makes it too easy to track users. From Lets Encrypt[1]: We ended support for OCSP primarily because it represents a considerable risk to privacy on the Internet. When someone visits a website using a browser or other software that checks for certificate revocation via OCSP, the Certificate Authority (CA) operating the OCSP responder immediately becomes aware of which website is being visited from that visitor’s particular IP address. Even when a CA intentionally does not retain this information, as is the case with Let’s Encrypt, it could accidentally be retained or CAs could be legally compelled to collect it. CRLs do not have this issue. [1]: https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-end-of-life https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-...
- johncolanduoni 10mo ago
  Client-side OCSP makes it too easy to track users. OCSP stapling largely solves that (plus the latency/fail-open issues) by having the server staple a recent OCSP response to the certificate during TLS negotiation. If OCSP stapling had succeeded, the privacy issues would have mostly disappeared (you could track that a server was serving traffic for a domain, but not the users).
  - tatersolid 10mo ago

the8472 10mo ago

> They're just breaking shit to make the world a worse place. Well, it's the people who want to MITM that started it, a lot of effort has been spent on a red queen's race ever since. If you humans would coordinate to stay in high-trust equilibria instead of slipping into lower ones you could avoid spending a lot on security.

deleted 10mo ago

[deleted]