Hi, I just wonder whether this is a bug in openSSL or in openLDAP, anyhow the subjectAltName attribute values are nor honoured. openssl-0.9.8k-3.5.3.x86_64 openldap-2.4.21
ldapwhoami -Y EXTERNAL -ZZ -H ldap://localhost ldap_start_tls: Connect error (-11) additional info: TLS: hostname does not match CN in peer certificate
openssl x509 -in cert.pem -noout -text Subject: C=DE, L=Hamburg, O=AVCI, OU=Certificate Authority, CN=rubin.avci.de/emailAddress=hdk@dkluenter.de ... X509v3 Subject Alternative Name: DNS:localhost, DNS:ldap.xxxx.de, DNS:dkluenter.xxxx.org
Not to mention that this is OK with other versions of openldap and openssl.
-Dieter
--On Tuesday, January 12, 2010 8:14 PM +0100 Dieter Kluenter dieter@dkluenter.de wrote:
Hi, I just wonder whether this is a bug in openSSL or in openLDAP, anyhow the subjectAltName attribute values are nor honoured.
I'd say it is a bug in one of them, yep. Why don't you change versions of one of the two and isolate it? :)
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Dieter Kluenter wrote:
Hi, I just wonder whether this is a bug in openSSL or in openLDAP, anyhow the subjectAltName attribute values are nor honoured. openssl-0.9.8k-3.5.3.x86_64 openldap-2.4.21
ldapwhoami -Y EXTERNAL -ZZ -H ldap://localhost ldap_start_tls: Connect error (-11) additional info: TLS: hostname does not match CN in peer certificate
openssl x509 -in cert.pem -noout -text Subject: C=DE, L=Hamburg, O=AVCI, OU=Certificate Authority, CN=rubin.avci.de/emailAddress=hdk@dkluenter.de ... X509v3 Subject Alternative Name: DNS:localhost, DNS:ldap.xxxx.de, DNS:dkluenter.xxxx.org
Not to mention that this is OK with other versions of openldap and openssl.
-Dieter
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.
Howard Chu wrote:
Dieter Kluenter wrote:
I just wonder whether this is a bug in openSSL or in openLDAP, anyhow the subjectAltName attribute values are nor honoured. openssl-0.9.8k-3.5.3.x86_64 openldap-2.4.21
ldapwhoami -Y EXTERNAL -ZZ -H ldap://localhost ldap_start_tls: Connect error (-11) additional info: TLS: hostname does not match CN in peer certificate
openssl x509 -in cert.pem -noout -text Subject: C=DE, L=Hamburg, O=AVCI, OU=Certificate Authority, CN=rubin.avci.de/emailAddress=hdk@dkluenter.de ... X509v3 Subject Alternative Name: DNS:localhost, DNS:ldap.xxxx.de, DNS:dkluenter.xxxx.org
Not to mention that this is OK with other versions of openldap and openssl.
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.
Ciao, Michael.
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. This has been a feature of libldap since 2.1, so it's certainly nothing new.
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.
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?
Ciao, Michael.
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.
Laziness, and the ubiquity of "localhost" in canned configs...
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?
I'm sure we have. Replacing "localhost" with the output of gethostname() is still inherently secure.
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
Philip Guenther wrote:
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? :-)
I'm not the original poster having an issue.
Ciao, Michael.
Howard Chu hyc@symas.com writes:
Dieter Kluenter wrote:
Hi, I just wonder whether this is a bug in openSSL or in openLDAP, anyhow the subjectAltName attribute values are nor honoured. openssl-0.9.8k-3.5.3.x86_64 openldap-2.4.21
ldapwhoami -Y EXTERNAL -ZZ -H ldap://localhost ldap_start_tls: Connect error (-11) additional info: TLS: hostname does not match CN in peer certificate
openssl x509 -in cert.pem -noout -text Subject: C=DE, L=Hamburg, O=AVCI, OU=Certificate Authority, CN=rubin.avci.de/emailAddress=hdk@dkluenter.de ... X509v3 Subject Alternative Name: DNS:localhost, DNS:ldap.xxxx.de, DNS:dkluenter.xxxx.org
Not to mention that this is OK with other versions of openldap and openssl.
[...]
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.
Found the culprit. As usual it is my beloved Yast :-) This is a new setup of openSUSE-11.2, /etc/hosts has following entries:
127.0.0.1 localhost ::1 localhost ipv6-localhost ipv6-loopback [ more ipv6 entries ] 127.0.0.2 rubin rubin 192.168.100.16 rubin.avci.de rubin [ more entries ]
removing the 127.0.0.2 entry solved ist.
-Dieter
openldap-software@openldap.org
-
Dieter Kluenter -
Howard Chu -
Michael Ströder -
Philip Guenther -
Quanah Gibson-Mount