Accepting TLS certificate hostnames based on IP address checks is not safe

April 24, 2020

The people running GMail are neither stupid nor ignorant, so presumably they had good reason for GMail not verifying TLS server hostnames until recently. When I was thinking about this yesterday, it occurred to me that one approach to safely accept TLS certificates even with mis-matched hostnames might be to look up the IP address of the host the certificate is for and accept it if the IP address is the same as what you're connecting to. Unfortunately, I then realized that this is not safe, at least in general; in fact accepting TLS certificate hostnames based on matching IP addresses is very dangerous and wrong.

The easiest way to see why this is very bad is to consider a captive portal with a DNS server that maps all hostname lookups to the same IP address, on which it has a web server listening. If this web server has a valid TLS certificate for its official public name, using 'is this the same IP address as the certificate hostname' will accept the server's TLS certificate for every HTTPS connection, for all hosts. After all, they all map to the same IP address. Facebook? Twitter? GMail? You name it, the captive portal's TLS certificate is valid for all of them under that test.

But suppose that you could be very confident that you have the genuine IP address for both hostnames (perhaps due to DNSSEC) and they're the same. This is no longer the general situation and the TLS certificate is now strong evidence that you're talking to the server (well, the IP address) that handles the host you want. However, my view is that you still shouldn't accept the TLS certificate, because verifying that you have the right server is only half of why you verify the hostname; the other reason is to verify that the server thinks it's supposed to handle this hostname. Since the TLS certificate lacks the right hostname, you don't have good assurance of that and shouldn't normally proceed.

Since people do sometimes get this wrong (as we did), it would be nice to have an additional way to verify a TLS certificate. But if there could be one, the IP address of the hostnames involved is not it.

(I'm writing this down partly so that perhaps I can remember the logic here the next time I have this clever idea.)

Written on 24 April 2020.
« The Unix divide over who gets to chown things, and (disk space) quotas
Some notes on Firefox's interstitial warning for old TLS versions »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Apr 24 00:35:28 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.