Re: start_tls: connect error

[Philip Guenther <guenther+ldapsoft@sendmail.com>]

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