Risks of getting hostname for SSL cert verification via forward-confirmed reverse DNS lookup of user-supplied IP?

Question

My understanding after reading other questions here is that an attacker would need control of the nameserver or the ability to forge responses from it to exploit this. Could it be abused in other ways?

For context, we have an application that connects to an LDAP server, optionally over SSL, to retrieve info about a domain. Customers configure the connection with a hostname or IP address, port, credentials, etc. Most of these servers are on internal networks, but some are public.

The current certificate verification code doesn't correctly verify the hostname in the server cert, which we're now fixing. The problem is that many customers have set the host to an IP address. To avoid breaking their setups on upgrade, we're thinking of using FCrDNS to get the hostname if the IP address isn't in the cert's subject alt names.

Answer 1

TLS using a domain name is resistant against DNS spoofing since the expectation given by the user (domain name) is checked directly against the certificate without any additional party involved. While DNS spoofing might result in the client connecting to the wrong server, the certificate check will fail (assuming strict checks and no compromised certificate) before any application data are transmitted.

Your approach instead relies on the security of DNS. While forward-confirmed DNS lookup is definitely more secure than a simple reverse lookup, it is still vulnerable to DNS spoofing attacks unless DNS itself is secured against such attacks (using DNSSec).

Thus, your approach is not as secure as checking against a user provided domain name. But it is definitely far more secure than not checking the subject of the certificate at all as was done in the past. If this "far more secure" can be considered "sufficiently secure" you have to decide yourself based on the specific risks in your environment.