13 ms·
I can see how this would work on a technical level but what's the intended use case?
by mocko 1y ago
I can see how this would work on a technical level but what's the intended use case?
- charcircuit 1y agoIt helps break free of ICANN's domain name system. This enables for competitors to support https without needing self signed certs.
- throitallaway 1y agoI'm guessing mostly hobbyists and one-off use cases where people don't care to associate a hostname to a project.
- BiteCode_dev 1y agoStatic ip for self hosting at home
- politelemon 1y agoThe validity is just 6 days, so I'd assume it's not for long lived use cases? Or am I misunderstanding something
- remram 1y agoYou can point a name at your home IP just as easily as any other IP.
- bravesoul2 1y agoBut you have to pay and involve a 3rd party.
- kingstnap 1y agoAre there ISPs that give you free static ips? Maybe for ipv6?
- bravesoul2 1y agoProbably not these days for v4
- ff317 1y agoIt might be interesting for "opportunistic" DoTLS towards authdns servers, which might listen on the DoTLS port with a cert containing a SAN that matches the public IP of the authdns server. (You can do this now with authdns server hostnames, but there could be many varied names for one public authdns IP, and this kinda ties things together more-clearly and directly).
- jeroenhd 1y agoIt might also he useful to hide the SNI in HTTPS requests. With the current status of ESNI/ECH you need some kind of proxy domain, but for small servers that only host a few sites, every domain may be identifiable (as opposed to, say, a generic Cloudflare certificate or a generic Azure certificate).
- bongodongobob 1y agoPretty common to have appliances without DNS entries in infra is my guess, I could def make use of this at work.
- Hizonner 1y agoYou're not going to be able to get a cert for any address that's not both (a) global, and (b) actually reachable from the Internet.
- teaearlgraycold 1y agoNot common, but there is the use case of vanity IPs. The cert for https://1.1.1.1 https://1.1.1.1 is signed for the IP as well as the domain name one.one.one.one
- szszrk 1y agoSometimes you want to have valid certs while your dns is undergoing major redesign. For instance to keep your dashboards available, or to be triple sure no old automation will fail due to dns issues. 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.
- Hizonner 1y agoSo go to keys-are-names. There's no reason AT ALL to bring IP addresses into the mix.
- szszrk 1y ago> So go to keys-are-names. 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.
- Hizonner 1y ago>> So go to keys-are-names. > 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:// 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).
- move-on-by 1y agoPlenty of other responses with good use cases, but I didn’t see NTS mentioned. 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.
- Hizonner 1y agoHow are you going to validate an X.509 certificate if you don't know the time?
- move-on-by 1y agoOh this is a good point! Looking at my DNSSEC domain (hosted by CloudFlare) on https://dnssec-debugger.verisignlabs.com https://dnssec-debugger.verisignlabs.com - the Inception Time and Expiration Time seems to be valid for... 3.5 days? This isn't something I look at much, but I assume that is up to the implementation. The new shortlived cert is valid for 6 days. So, from a very rough look, I expect X.509 certificate is going to be less time sensitive then DNSSEC - but only by a few days. Also, very likely to depend on implementation details. This is a great point.
- dcow 1y agoPractically, though, you rely on hardware time until you get network time.
- dgl 1y agoChromeOS has a quite interesting design to do this: https://www.chromium.org/chromium-os/chromiumos-design-docs/timekeeping/#tlsdate https://www.chromium.org/chromium-os/chromiumos-design-docs/... Essentially: keep some minimum values for time. Then do a single HTTPS request, ignore the validation of the certificate's date to start with, but use the Date header to later validate it against minimum / maximum. This has the advantage it's still a HTTPS request, so can't be MiTM'd and depending on implementation it can validate the time quite well (even if the device has run out of power it can have saved a recent timestamp on disk, so with regular use of the device an old certificate won't be valid, keeping the main useful property of certificates having validity periods). I don't believe it does this, but you could do this without DNS as 8.8.8.8, etc already have IP address certificates: curl -sI https://1.1.1.1 | grep -i '^date:' curl -sI https://8.8.8.8 | grep -i '^date:' curl -sI https://9.9.9.9 | grep -i '^date:' It would need a custom tool though, as curl only has --insecure, not a way to avoid just the notBefore / notAfter validation of the cert. (This is not the only thing to use this technique, OpenBSD's ntpd has a way to contrain time based on HTTP headers: https://man.openbsd.org/ntpd.conf#CONSTRAINTS https://man.openbsd.org/ntpd.conf#CONSTRAINTS -- the default ntpd.conf ships with Quad9 configured via IP address.)
- infogulch 1y agoJust ESNI/ECH is a big deal. 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.
- duskwuff 1y ago> If it becomes common enough for clients to assume that all web servers have an IP cert That's never going to be a safe assumption; private and/or dynamically assigned IP addresses are always going to be a thing.
- Hizonner 1y agoSo is this the flow? 1. Want to connect to https://www.secret.com 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?
- 1y ago
- spelunker 1y agoMight be nice for local/development environment work. Test HTTPS without needing to set up `my-dev-env.staging.service.com` or whatever.
- hypeatei 1y agoOne use-case is connecting to a DoT (DNS-over-TLS) server directly rather than using a hostname. If you make a TLS connection to an IP address via OpenSSL, it will verify the IP SAN and fail if it's not there.
- Am4TIfIsER0ppos 1y agoThe intended use case is to forbid plain http so that you can't communicate with the computer in the next room without 3rd party permission.
- deleted 1y ago[deleted]