0

Using DNSSEC you can be sure that you have the right IP for a domain and using a certificate for the IP signed by someone you trust you know you have the right IP.

Shouldn't this be enough to know the connection is correct? Why would the domain name be needed in the certificate used by the server?

Mikael Dúi Bolinder
  • 109
  • 5
  • domain names are externally verifiable, IPs, notsomuch. – dandavis Jun 06 '19 at 20:02
  • 1
    Looks that you are mixing DNSSEC and certificates, that's DANE from my understanding, it would be a good idea if you search for it, might respond your question – camp0 Jun 06 '19 at 20:08
  • @dandavis what do you mean? https://1.1.1.1 https://stackoverflow.com/questions/2043617/is-it-possible-to-have-ssl-certificate-for-ip-address-not-domain-name – Mikael Dúi Bolinder Jun 06 '19 at 20:40
  • 1
    yes, it could have worked this way in an alternate reality. but dnssec failed miserably, the internet got built with everyone knowing not to trust dns, and we have domain name certs and acme protocol. – Z.T. Jun 06 '19 at 20:49
  • @camp0 very much like DANE except for mandatory CA's. Related DANE question: https://security.stackexchange.com/a/749/45914 – Mikael Dúi Bolinder Jun 07 '19 at 15:20
  • And how do you handle "domains" being load balancers and CDNs that will resolve to different IP addresses through both space and time? Or someone just changing its webhosting provider, and hence seeing his "domain" (more precisely its website) from IP1 to IP2? – Patrick Mevzek Jun 09 '19 at 05:22
  • @PatrickMevzek how would it not work? If the load balancers and CDNs IP's are listed (which they must for users to be able to find and access them) they will be valid/trusted. – Mikael Dúi Bolinder Jul 02 '19 at 10:57
  • 1
    A given name can resolve to IP1 now, and IP2 in 5 minutes. A given name can resolve to IP1 if requested from location X, but to IP2 from location Y at the same time. There is a lot of volatility in both space and time. How do you propose handling certificates for all these IPs? – Patrick Mevzek Jul 02 '19 at 14:49
  • @PatrickMevzek that issue is the same as for the corrent way the web works. – Mikael Dúi Bolinder Jul 03 '19 at 16:11
  • You miss a big difference: the content comes from only one source, the server. The certificate, does indeed come from the server too, but was validated/signed/issued by a third party, which clients will trust. So it is not purely under control of the server (except for private certificates of course, but then they may not be accepted by clients). – Patrick Mevzek Sep 09 '19 at 16:46
  • @PatrickMevzek there may be multiple servers (IPs) serving the same domain. I still find my finding 100% legit and something I'd trust. – Mikael Dúi Bolinder Sep 09 '19 at 23:31

2 Answers2

1

Domain names are a different addressing scheme than IP addresses: There might be multiple IP addresses for the same domain name and there can also be multiple domains on the same IP address. And these domains can serve different contents too, even if they have the same IP address (at least with HTTPS).

Only if there is a 1:1 relation between IP and domain name you could replace one with the other, i.e. connect to some domain by lookup up the IP address and then check if the IP address is contained in the certificate instead of looking for the domain name. But neither plain DNS nor DNSSec provide you with the information if this is a 1:1 mapping. Even if you get only a single IP address when looking up a domain it might still be possible that you get the same IP address when looking up other domains.

Because of that you have to check the subject/SAN of the certificate against your original expectation (domain name) and not against some derived expectation (IP address).

Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
  • Why would there have to be a 1:1 mapping? There can be multiple A records and multiple A records can point to the same IP. – Mikael Dúi Bolinder Jun 06 '19 at 23:15
  • 1
    @MikaelDúiBolinder: I'm not talking about A records but about IP addresses which you get as a result of the DNS lookup. But the major issue is if multiple domains point to the same IP address, that these domains are owned and controlled by different parties and that these domains serve different contents - which is a very common configuration in shared hosting. In this case how do you know from the certificate which of these domains it belongs too if it contains only the IP address but not the domain name. – Steffen Ullrich Jun 07 '19 at 03:34
  • the domain owner authorized that IP/server when adding the IP to the domains signed zone. – Mikael Dúi Bolinder Jun 07 '19 at 14:57
  • 1
    @MikaelDúiBolinder: anybody can claim that his domain resolves to a specific IP address. DNSSec provides only a signed record for a mapping from name to IP address but this can not be used as a proof that this is the only domain resolving to the specific IP address. – Steffen Ullrich Jun 07 '19 at 16:58
  • multiple domains should be able to resolve to the same IP address. The IP address doesn't have to host all domains. – Mikael Dúi Bolinder Jun 20 '19 at 23:16
1

The wording of your question implies that this would somehow be easier than what we have now, but the reality is quite the opposite.

Firstly, DNS as implemented today is strictly hierarchical. That puts constraints on how DNS records can be signed, because you need to trust every zone back to the root not to have been substituted. This is rather different from the ability to prove ownership (or at least control) to any third party, as is done with domain certificates.

Secondly, IP address allocation is complex, and often dynamic. A certificate for ownership of an IP address would need a short lifetime, and to be obtainable at short notice. There's also a question of how exactly ownership would be proven to the certifying authority.

Assuming these difficulties were overcome, you've still got two systems of signatures instead of our current one. While a more secure DNS would be beneficial for issuing certificates, an end-user checking the connection in our current system doesn't need it. If the DNS record is forged, it will point to a server which doesn't have a valid certificate for the requested domain, so the connection will be rejected.

IMSoP
  • 3,790
  • 1
  • 15
  • 19