openldap-bugs February 2009

openldap-bugs@openldap.org

47 participants
298 discussions

Re: (ITS#5938) tls.c does not conform to RFC 4513
by Kurt＠OpenLDAP.org 10 Feb '09

10 Feb '09

On Feb 10, 2009, at 8:29 AM, h.b.furuseth(a)usit.uio.no wrote: > quanah(a)zimbra.com writes: >> This is because the Cert vendors themselves don't honor the RFC's >> when >> issuing wildcard certs, and was added so that their broken wildcard >> certs could still be used. > > In that case, maybe there should be a config option to turn this > behavior on/off, and documentation which explains that it breaks TLS > the standard and why it does so. I think it reasonable to be liberal in what we accept in this particular case. It's not like someone is actually going to name a host '*'. If they do, their certificate matching more hosts than they expect will be just one of many problems they face. > > > If nothing else, it may get more people to complain to the cert > vendors. Far more persons would complain to the OpenLDAP Project.

1 0

Re: (ITS#5938) tls.c does not conform to RFC 4513
by h.b.furuseth＠usit.uio.no 10 Feb '09

10 Feb '09

quanah(a)zimbra.com writes: > This is because the Cert vendors themselves don't honor the RFC's when > issuing wildcard certs, and was added so that their broken wildcard > certs could still be used. In that case, maybe there should be a config option to turn this behavior on/off, and documentation which explains that it breaks TLS the standard and why it does so. If nothing else, it may get more people to complain to the cert vendors. -- Hallvard

1 0

Re: (ITS#5938) tls.c does not conform to RFC 4513
by Kurt＠OpenLDAP.org 10 Feb '09

10 Feb '09

On Feb 10, 2009, at 7:56 AM, nick.hudson(a)isode.com wrote: > Full_Name: nick hudson > Version: 2.3.38 > OS: linux > URL: > Submission from: (NULL) (62.3.217.250) > > > I am looking at the code in tls.c, function > ldap_pvt_tls_check_hostname > (although the code has been refactored in recent versions, into e.g. > tls_o.c, > but the same is true of the new code) > > I think the code is doing something that RFC 4513 says that it > should not do. > Specifically, ref RFC 4513 section 3.1.3 says: > > The server's identity may also be verified by comparing the > reference > identity to the Common Name (CN) [RFC4519] value in the leaf > Relative > Distinguished Name (RDN) of the subjectName field of the server's > certificate. This comparison is performed using the rules for > comparison of DNS names in Section 3.1.3.1, below, with the > exception > that no wildcard matching is allowed. > > In tls.c (and the refactored code), you can see it's first > attempting an exact > comparison on subjectAltName, and if that fails it tries a wildcard > match (which > is ok, as per section 3.1.3.1) > > But if no subjectAltName match is found, there's another section > which looks at > the certificate's subjectname, in which it also does a wildcard > match, although > the RFC says this shouldn't be done. This is a case where OpenLDAP library is purposely being 'liberal in what it accepts'. -- Kurt

1 0

Re: (ITS#5938) tls.c does not conform to RFC 4513
by quanah＠zimbra.com 10 Feb '09

10 Feb '09

--On February 10, 2009 3:56:37 PM +0000 nick.hudson(a)isode.com wrote: > Full_Name: nick hudson > Version: 2.3.38 > OS: linux > URL: > Submission from: (NULL) (62.3.217.250) > > > I am looking at the code in tls.c, function ldap_pvt_tls_check_hostname > (although the code has been refactored in recent versions, into e.g. > tls_o.c, but the same is true of the new code) > > I think the code is doing something that RFC 4513 says that it should not > do. Specifically, ref RFC 4513 section 3.1.3 says: > > The server's identity may also be verified by comparing the reference > identity to the Common Name (CN) [RFC4519] value in the leaf Relative > Distinguished Name (RDN) of the subjectName field of the server's > certificate. This comparison is performed using the rules for > comparison of DNS names in Section 3.1.3.1, below, with the exception > that no wildcard matching is allowed. > > In tls.c (and the refactored code), you can see it's first attempting an > exact comparison on subjectAltName, and if that fails it tries a wildcard > match (which is ok, as per section 3.1.3.1) > > But if no subjectAltName match is found, there's another section which > looks at the certificate's subjectname, in which it also does a wildcard > match, although the RFC says this shouldn't be done. This is because the Cert vendors themselves don't honor the RFC's when issuing wildcard certs, and was added so that their broken wildcard certs could still be used. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5939) Missing close of file descriptor
by joakim.bentholm＠birdstep.com 10 Feb '09

10 Feb '09

Full_Name: Joakim Bentholm Version: OpenLDAP 2.4.13 OS: FreeBSD 7.0 Release URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.13.255.38) The running setup: An ldap server with a socket back-end communicating with server process listening on incoming requests from the socket back-end and replying in an orderly fashing. The failure: If the server process shuts down, the socket back-end will continue to try to connect and allocating new file descriptors which will never be released. If the server process is restarted everything will work, unless the file descriptor limit have been reached, in case the ldap server have to be restart. Solution: close the file descripton The following patch solves the problem --- --- servers/slapd/back-sock/opensock.c.orig 2008-02-09 01:46:09.000000000 +0100 +++ servers/slapd/back-sock/opensock.c 2009-02-02 16:09:24.000000000 +0100 @@ -57,6 +57,7 @@ if ( connect( fd, (struct sockaddr *)&sockun, sizeof(sockun) ) < 0 ) { Debug( LDAP_DEBUG_ANY, "socket connect(%s) failed\n", sockpath ? sockpath : "<null>", 0, 0 ); + close( fd ); return( NULL ); } ---

1 0

(ITS#5938) tls.c does not conform to RFC 4513
by nick.hudson＠isode.com 10 Feb '09

10 Feb '09

Full_Name: nick hudson Version: 2.3.38 OS: linux URL: Submission from: (NULL) (62.3.217.250) I am looking at the code in tls.c, function ldap_pvt_tls_check_hostname (although the code has been refactored in recent versions, into e.g. tls_o.c, but the same is true of the new code) I think the code is doing something that RFC 4513 says that it should not do. Specifically, ref RFC 4513 section 3.1.3 says: The server's identity may also be verified by comparing the reference identity to the Common Name (CN) [RFC4519] value in the leaf Relative Distinguished Name (RDN) of the subjectName field of the server's certificate. This comparison is performed using the rules for comparison of DNS names in Section 3.1.3.1, below, with the exception that no wildcard matching is allowed. In tls.c (and the refactored code), you can see it's first attempting an exact comparison on subjectAltName, and if that fails it tries a wildcard match (which is ok, as per section 3.1.3.1) But if no subjectAltName match is found, there's another section which looks at the certificate's subjectname, in which it also does a wildcard match, although the RFC says this shouldn't be done.

1 0

Re: (ITS#5937) Apparent mistake in ipv6 address handling in tls.c
by hyc＠symas.com 10 Feb '09

10 Feb '09

Kurt Zeilenga wrote: > On Feb 10, 2009, at 4:27 AM, hyc(a)symas.com wrote: >> Nice catch, that's been in there since 2002. Fixed in HEAD. > > I counted 5 occurs in HEAD tls*.c... 2 of those are in tls.c, which is no longer being compiled. I just haven't got around to cvs rm'ing it yet after splitting to tls2.c and the other modules. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5937) Apparent mistake in ipv6 address handling in tls.c
by Kurt＠OpenLDAP.org 10 Feb '09

10 Feb '09

On Feb 10, 2009, at 4:27 AM, hyc(a)symas.com wrote: > nick.hudson(a)isode.com wrote: >> Full_Name: nick hudson >> Version: 2.3.38 >> OS: linux >> URL: >> Submission from: (NULL) (62.3.217.250) >> >> >> I think there is a bug in libraries/libldap/tls.c - specifically in >> this >> section: >> >> #ifdef LDAP_PF_INET6 >> if (name[0] == '['&& strchr(name, ']')) { >> char *n2 = ldap_strdup(name+1); >> *strchr(n2, ']') = 2; >> if (inet_pton(AF_INET6, n2,&addr)) >> ntype = IS_IP6; >> LDAP_FREE(n2); >> } else >> #endif >> >> the code is attempting to detect whether part of an LDAP URL >> represents an IPv6 >> address; it passes the string to inet_pton(), after removing square >> brackets. >> But I think this line: >> >> *strchr(n2, ']') = 2; >> >> is wrong: shouldn't it be using 0 instead of 2? >> >> When testing on my local system, using the code above always >> results in >> inet_pton returning 0 (not an IPv6 address) - if I modify the >> strchr line to use >> zero instead, then inet_pton returns 1 for valid IPv6 addresses. >> >> I may be missing something - "2" seems a peculiar value to use so >> perhaps it >> does have some special significance - but I think the code as it >> stands is >> incorrect. > > Nice catch, that's been in there since 2002. Fixed in HEAD. I counted 5 occurs in HEAD tls*.c... -- Kurt

1 0

Re: (ITS#5936) test049 uses nonexistant variable SLEEP1
by hyc＠symas.com 10 Feb '09

10 Feb '09

jclarke(a)linagora.com wrote: > Full_Name: Jonathan Clarke > Version: RE24 > OS: irrelevant > URL: http://milopita.phillipoux.net/jonathan-clarke-20090210-test049.patch > Submission from: (NULL) (213.41.243.192) > > > test049 complains with: > Waiting seconds for syncrepl to receive changes... > sleep: missing operator > > The patch below corrects this. Using 10 seconds as default value, as is done > above in the test script for cn=config replication. > > > Thanks, fixed. I guess we probably should just sync up the rest of the test scripts between HEAD and RE24 after all, since we've tripped over this a few times already. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5937) Apparent mistake in ipv6 address handling in tls.c
by hyc＠symas.com 10 Feb '09

10 Feb '09

nick.hudson(a)isode.com wrote: > Full_Name: nick hudson > Version: 2.3.38 > OS: linux > URL: > Submission from: (NULL) (62.3.217.250) > > > I think there is a bug in libraries/libldap/tls.c - specifically in this > section: > > #ifdef LDAP_PF_INET6 > if (name[0] == '['&& strchr(name, ']')) { > char *n2 = ldap_strdup(name+1); > *strchr(n2, ']') = 2; > if (inet_pton(AF_INET6, n2,&addr)) > ntype = IS_IP6; > LDAP_FREE(n2); > } else > #endif > > the code is attempting to detect whether part of an LDAP URL represents an IPv6 > address; it passes the string to inet_pton(), after removing square brackets. > But I think this line: > > *strchr(n2, ']') = 2; > > is wrong: shouldn't it be using 0 instead of 2? > > When testing on my local system, using the code above always results in > inet_pton returning 0 (not an IPv6 address) - if I modify the strchr line to use > zero instead, then inet_pton returns 1 for valid IPv6 addresses. > > I may be missing something - "2" seems a peculiar value to use so perhaps it > does have some special significance - but I think the code as it stands is > incorrect. Nice catch, that's been in there since 2002. Fixed in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

← Newer
1
...
15
16
17
18
19
20
21
...
30
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2009