←back to thread

314 points Bogdanp | 1 comments | | HN request time: 0.204s | source
Show context
mocko ◴[] No.44379696[source]
I can see how this would work on a technical level but what's the intended use case?
replies(13): >>44379710 #>>44379735 #>>44379778 #>>44379786 #>>44379885 #>>44379946 #>>44380155 #>>44380377 #>>44380579 #>>44380856 #>>44381151 #>>44381389 #>>44386646 #
szszrk ◴[] No.44379946[source]
Sometimes 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.

replies(1): >>44380116 #
Hizonner ◴[] No.44380116[source]
So go to keys-are-names.

There's no reason AT ALL to bring IP addresses into the mix.

replies(2): >>44380212 #>>44382552 #
szszrk ◴[] No.44380212[source]
> 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.

replies(2): >>44380427 #>>44383376 #
Hizonner ◴[] No.44380427[source]
>> 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:// 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).

replies(2): >>44380759 #>>44380991 #
freeone3000 ◴[] No.44380759[source]
The BSD networking stack treats an IP addr as a valid hostname for hostname resolution. As such, every phone, tablet, and computer able to do TLS by hostname can do it by IP. Try it out! Self-sign an IP certificate and try it on your local net. If you put it in the trust store, it’ll validate just fine. The only barrier to adoption was CAs refusing to issue IP certificates at large.
replies(2): >>44380835 #>>44380861 #
1. mananaysiempre ◴[] No.44380861[source]
Noot quite. DNS hostnames and IP addresses are encoded differently in X.509 certs: one is the dNSName option of the GeneralName choice type in the subjectAltName extension[1], the other is the iPAddress option. (And before you ask, tagging a stringified IP address quad as a dNSName is misissuance per the CA/Browser Forum Baseline Requirements[2] and liable to get your CA kicked from certificate stores. Ambiguous encodings are dangerous.) So some explicit support from the TLS library is indeed required. But I’m indeed not aware of many apps having problems with IP address certs.

[1] https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1....

[2] https://cabforum.org/working-groups/server/baseline-requirem...