On Wed, 13 Jan 2010, Michael Ströder wrote:
Howard Chu wrote:
Michael Ströder wrote:
Howard Chu wrote:
Show the output with debugging enabled. Note that "localhost" is treated specially, and will be replaced by the local hostname instead of being used directly in the name comparison.
Why that? I strongly dislike automagic things when doing security checks.
Probably because "localhost" is useless in an actual cert from a remote server.
Yes. But nothing prevents the client from providing the correct hostname.
True, so why didn't you? :-)
Isn't the problem scenario that if you're going to look up "DNS:localhost" in the subjectAltName of server certs, then you're expecting CAs to issue those; if there's more than one cert with that subjectAltName signed by trusted CAs, then your TLS certificate name checking will not detect redirection of connections among those hosts, creating an attack vector.
This has been a feature of libldap since 2.1, so it's certainly nothing new.
You can blame me that I did not notice this feature before. Still I think that's broken since libldap has to rely on a trustworthy name resolving then instead of just comparing the inherently trusted user input against the cert's CN attribute. Hmm, didn't we have this discussion before?
You're referring to name resolution for what purpose? If I'm reading the libldap code correctly, the remapping of "localhost" to gethostname() is only for the TLS certificate name checking and not part of the connect-to-URL code. I.e., "ldap://localhost" still does a host->address lookup for "localhost" when opening the TCP connection; it's only when it checks certs in the StartTLS op that it uses the local hostname.
Philip Guenther