In other cases dns is just not needed at all. You might prefer simplicity, independence from dns propagation, so you will have your, say, Cockpit exposed instantly on a test env.
Only our imagination limits us here.
There's no reason AT ALL to bring IP addresses into the mix.
Elaborate, please.
> There's no reason AT ALL to bring IP addresses into the mix.
Not sure what scenario you are talking about, but IPs are kind of hard to avoid. DNS is trivial to avoid - you can simply not set it up.
"bringing IPs into the mix" is literally the only possible option.
> Elaborate, please.
Identify a service directly by its crypto key. When you configure something else to connect to it, treat the IP address as a hint, not the primary identifier for what it's talking to. Standard idiom.
... and before you tell me that that's infeasible because you'd have to modify software, go do a survey of all the code out there, and see how much of it supports IP address certificates. If you're moving around the parts of some big complex system, it's pretty much guaranteed that many of those parts are going to choke if you just blindly go and stick IP addresses in https:// URLs.
And if you're fixing the software anyway, then it's not sane to "fix" it to attach identity to something you're going to want to change all the time, like an IP address. Especially if they're global addresses (which are the only ones any Let's Encrypt or any other public CA is ever going to certify) in the IPv4 space (which is the only one any "enterprise" ever seems willing to use).
[1] https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1....
[2] https://cabforum.org/working-groups/server/baseline-requirem...
I've been doing that for years on onprem (~60% old "enterprise/legacy" ~40% modern stuff) and never seen anything that doesn't support it. YMMV, but if all I work with supports it, I won't complain in vain.
> those parts are going to choke if you just blindly go and stick IP addresses in https:// URLs.
I did many times, seems that legacy heavens were always kind to me in this regard.
> something you're going to want to change all the time, like an IP address
That's a personal assumption as well. If your architectures change IPs all the time, OK. Ones I worked with didn't. Always had plenty of components with IPs that didn't changed in a decade or two. Even my two previous local ISPs I had gave me "dynamic public IP" and kept them for many years. For some companies changing an ip of their main firewalls/load balancers or VPN servers is unthinkable.
Even on my last project on Public Cloud, the first thing I did was to make sure public IPs won't be dynamic (will survive recreation of services) so I don't have to deal with consequences of my corporate client endpoints and proxies flushing DNS caches randomly. (don't ask me why, but even huge companies still use proxies on a large scale. Good luck with figuring out when such proxy invalidates your DNS record).
> in the IPv4 space
IPv6 is here. Your printer and light bulb will want a cert as well.
If you want to use NTS, but can’t get an IP cert, then you are left requiring DNS before you can get a trusted time. If DNS is down- then you can’t get the time. A common issue with DNSSEC is having the wrong time- causing validation failures. If you have DNSSEC enforced and have the wrong time- but NTS depends on DNS, then you are out of luck with no way to recover. Having IP as part of your cert allows trusted time without the DNS requirement, which can then fix your broken DNSSEC enforcement.
I recall one of the main arguments against Encrypted server name indication (ESNI) is that it would only be effective for the giant https proxy services like Cloudflare, that the idea of IP certs was floated as a solution but dismissed as a pipe dream. With IP address certificates, now every server can participate in ESNI, not just the giants. If it becomes common enough for clients to assume that all web servers have an IP cert and attempt to use ESNI on every connection, it could be a boon for privacy across the internet.
That's never going to be a safe assumption; private and/or dynamically assigned IP addresses are always going to be a thing.
1. Want to connect to https://www.secret.com.
2. Resolve using DNS, get 1.2.3.4
3. Connect to 1.2.3.4, validate cert
4. Send ESNI, get separate cert for www.secret.com, validate that
... and the threat you're mitigating is presumably that you don't want to disclose the name "www.secret.com" unless you're convinced you're talking to the legitimate 1.2.3.4, so that some adversary can't spoof the IP traffic to and from 1.2.3.4, and thereby learn who's making connections to www.secret.com. Is that correct?
But the DNS resolution step is still unprotected. So, two broad cases:
1. Your adversary can subvert DNS. In this case IP certificates add no value, because they can just point you to 5.6.7.8, and you'll happily disclose "www.secret.com" to them. And you have no other path to communicate any information about what keys to trust.
2. Your adversary cannot subvert DNS. But if you can rely on DNS, then you can use it as a channel for key information; you include a key to encrypt the ESNI for "www.secret.com" in a DNS record. Even if the adversary can spoof the actual IP traffic to and from 1.2.3.4, it won't do any good because it won't have the private key corresponding to that ESNI key in the DNS. And those keys are already standardized.
So what adversary is stopped by IP certificates who isn't already stopped by the ESNI key records in the DNS?
> you include a key to encrypt the ESNI for "www.secret.com" in a DNS record
I've never heard of this, is this a thing that exists today? (edited to remove unnecessary comment)
see: https://en.wikipedia.org/wiki/Server_Name_Indication#Encrypt...
> Another Internet Draft incorporates a parameter for transmitting the ECH public keys via HTTPS and SVCB DNS record types, shortening the handshake process.[24][25]
[25]: Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings | https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/
Is this because the certificate was requested for the IP, and other DNS entries were part of the SAN?
This change has been made in short-lived (6 day) certificate profiles. It has not been made for the "classic" profile (90 day).
The only challenges possible are HTTP and TLS-ALPN, not DNS, so the "proof" that you own the IP is that LetsEncrypt can contact it?
Lots of sport here, unless perhaps they cool off IPs before reallocating, or perhaps query and revoke any certs before reusing the IP?
If the addressing bodies are not on board then it's a user responsibility to validate the host header and reject unwanted IP address based connections until any legacy certs are gone / or revoke any legacy certs. Or just wait to use your shiny new IP?
I wonder how many IP certs you could get for how much money with the different cloud providers.
I wonder if they'll offer wildcard certs at some point.
... or put multiple customers on the same IP address at the same time. But presumably they wouldn't be willing to complete the dance necessary to actually get certs for addresses they were using that way.
Just in case, though, it's probably a good idea to audit basically all software everywhere to make sure that it will not use IP-based SANs to validate connections, even if somebody does, say, embed a raw IP address in a URL.
This stuff is just insanity.
But there was no conclusion that customers on the same server can't get certificates just because they're on the same server, or that whoever legitimately controls the default server for an IP address can't get them.
This would be a problem if clients would somehow treat https://example.com/ and https://96.7.128.175/ as the same identifier or security context just because example.com resolves to 96.7.128.175, but I'm not aware of clients that ever do so. Are you?
If clients don't confuse these things in some automated security sense, I don't see how IP address certs are worse than (or different from) certs for different customers who are hosted on the same IP address.
The point was that it affects the utility of the idea.
... and don't get me started on those "challenge methods". Shudder. You'll have me ranting about how all of X.509 really just needs to be taken out and shot. See, I'm already doing it. Time for my medication...
>Lots of sport here, unless perhaps they cool off IPs before reallocating, or perhaps query and revoke any certs before reusing the IP?
I don't see how this is any different than custom/vanity domains you can get from cloud providers. For instance on azure you can assign a DNS name to your VMs in the form of myapp.westus.cloudapp.azure.com, and CAs will happily issue certificates for it[1]. There's no cooloff for those domains either, so theoretically someone else can snatch the domain from you if your VM gets decommissioned.
[1] https://crt.sh/?identity=westus.cloudapp.azure.com&exclude=e...
You can reclaim it during that time, but any other tenant/organization will get an error that the name is in use. You can ping support to help you there if you show them you own both organizations. I was doing a migration of some resources across organizations and ran into that issue
https://github.com/mozilla-firefox/firefox/blob/d5979c2a5c2e...
Yikes.
Which is an error. Any ip like 2001:0000:0000::1 is going to be incorrect. It willingly produces errors. Whoever wrote this didn't even spend a few seconds thinking about the structure of IPv6 addresses.
> I don't see anything problematic with it.
Other than it being completely wrong and requiring a regex to be compiled for an amount of work that's certainly less than the compilation itself.
This is neither a possible input nor a possible output of that code.
That's exceptionally presumptions to the point of being snotty.
> I think you are getting the causality wrong there.
Where did I imply causality? This was simply an occasion to look at the code. This is bad code. I would not pass this. What's your _justification_ for using a regex here?
So the first reason not to do it is that you never want to change software without a good reason. And none of the use cases anybody's named here so far hold water. They're all either skill issues already well addressed by existing systems, or fundamental misunderstandings that don't actually work.
Changing basic assumptions about naming is an extra bad idea with oak leaf clusters, because it pretty much always opens up security holes. I can't point to the specific software where somebody's made a load-bearing security assumption about IP address certificates not being available (more likely a pair of assumptions "Users will know about this" and "This can't happen/I forgot about this")... but I'll find out about it when it breaks.
Furthermore, if IP certificates get into wide use (and Let's Encrypt is definitely big enough to drive that), then basically every single validator has to have a code path for IP SANs. Saying "you don't have to use it" is just as much nonsense as saying "you don't have to use IP". Every X.509 library ends up with a code path for IP SANs, and it effectively can't even be profiled out. Every library is that much bigger and that much more complicated and needs that much more maintenance and testing. It's a big externalized cost. It would better to change the RFCs to deprecate IP SANs; they never should have been standardized to begin with.
It also encourages a whole bunch of bad practices that make networks brittle and unmaintainable. You should almost never see an IP address outside of a DNS zone file (or some other name resolution protocol). You can argue that people shouldn't do stupid things like hardwiring IP addresses even if they're given the tools... but that's no consolation to the third parties downstream of those stupid decisions.
... and it doesn't even work for all IP addresses, because IP addresses aren't global names. So don't forget to special-case the locally administered space in every single piece of code that touches an X.509 certificate.
I'm not sure why private IP addresses would need to be treated differently other than by the software that issues certs for publicly trusted CAs (which is highly specialized and can handle the few extra lines of code, it's not a big cost for the whole ecosystem). Private CAs can and do issue certs for private IP addresses.
Also, how would DoH or DoT work without this?
However, if a router manufacturer was so inclined, they _could_ have the device request a certificate for their public IPv4 address, given that it's not behind CG-NAT. v6 should be relatively easy since (unless you're at a cursed ISP) all v6 is generally globally routable.
For example you can use nginx manager if you want a ui and adguard for dns. Set your router to use adguard as the exclusive dns. Add a rewrite rule for your domain to point to the proxy. Register the domain and get a real cert. problem solved
All of my local services use https
Sigh... I wish people would use their words before trotting out possibly-ambiguous (or obscure) acronyms. It would help avoid confusion among readers who don't live and breathe the topic on the writer's mind.
(And my point applies to all writing and speaking, not just this post.)
zaik•4h ago
giancarlostoro•3h ago