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?
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?
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.
> 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.
> 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.
No, it's literally nothing, since you can just create whatever TLS cert you want and just MITM anyway.
What do you think you're protecting from? Passive snooping via port-mirroring?
Taps are generally more sophisticated than that.
How do I establish trust with Google? How do they establish trust with me: I mean, we're not using the system designed for it, so clearly it's not possible- otherwise they would have enabled this option at the minimum.
> No, it's literally nothing, since you can just create whatever TLS cert you want and just MITM anyway.
> What do you think you're protecting from? Passive snooping via port-mirroring?
Yes, exactly. For datacenter to datacenter traffic, passing snooping is much easier for small-time criminals to achieve than a MITM. You can do it just by having a device on the same L2 switch domain and spoofing the MAC table (MAC spoofing/port security being un- or mis-configured is typical in those environments). No need to compromise routing at all.
> How do I establish trust with Google? How do they establish trust with me: I mean, we're not using the system designed for it, so clearly it's not possible- otherwise they would have enabled this option at the minimum.
Establishing trust with Google specifically is super-simple: their SMTP servers all have valid public PKI certificates and have for a long time. Even if they didn’t, they could give you an internal CA root to verify them. This doesn’t scale to lots of orgs, but almost all legitimate email traffic is between Google, Microsoft, Yahoo, and the top 10 marketing/transactional email services.
That’s why nobody was in a rush to solve the SMTP MITM problem. Plus, since SMTP for delivery is not authenticated at the application level, you only have to really worry about snooping/preventing delivery. If you want to send fake emails, the certificates provided by the server are irrelevant - there’s no password that you need to steal.
Because the service needs to be usable from non-managed devices, whether that be on the internet or on an isolated wifi network.
Very common in mobile command centres for emergency management, inflight entertainment systems and other systems of that nature.
I personally have a media server on my home LAN that I let my relatives use when they’re staying at our place. It has a publicly trusted certificate I manually renew every year, because I am not going to make visitors to my home install my PKI root CA. That box has absolutely no reason to be reachable from the Internet, and even less reason to be allowed to modify my public DNS zones.
Sure, but in those examples - automation and short-lifetime certs are totally possible.
Except when it's not, because the system rarely (or never) touches the Internet.
It might never 'touch' the internet, but the certificates can be easily automated. They don't have to be reachable on the internet, they don't have to have access to modify DNS - but if you want any machine in the world to trust it by default, then yes - there'll need to be some effort to get a certificate there (which is an attestation that you control that FQDN at a point-in-time).
Right now that’s an email to an address listed in whois, and I’m happy to go in and click that link annually.
I don’t need to create any new and operationally unnecessary attack surface to prove that I control the domain.
and we're back to: How do I create an API token that only enables a single record to be changed on any major cloud provider?
Or.. any registrar for that matter (Namecheap, Gandi, Godaddy)?
The answer seems to be: "Bro, you want security so the way you do that is to give every device that needs TLS entire access to modify any DNS record, or put it on the public internet; that's the secure way".
(PS: the way this was answered before was: "Well then don't use LE and just buy a certificate from a major provider", but, well, now that's over).
There are ways to do this as pointed out below - CNAME all your domains to one target domain and make the changes there. There’s also a new DCV method that only needs a single, static record. Expect CA support widely in the coming weeks and months. That might help?
One answer I've seen to this (very legitimate) concern is using CNAME delegation to point _acme-challenge.$domain to another domain (or a subdomain) that has its own NS records and dedicated API credentials.
You know you don’t have to give it permission to a whole zone right?
My DNS provider has per-record permissions, but you could delegate a subdomain even if your DNS provider lacks per-record permissions.