4 ms·

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 A

by dijit 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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.

by dijit 11mo ago

johncolanduoni 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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.