openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

(ITS#6252) GnuTLS subjectAltNames broken
by quanah＠zimbra.com 13 Aug '09

13 Aug '09

Full_Name: Quanah Gibson-Mount Version: 2.4.17 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) GnuTLS fails to parse certain subjectAltNames and returns spurious SHORT_BUFFER error. We passed in a buffer size of 1025, and it's internally overwriting it with a size of only 31 and then complaining that 31 is too small

1 0

Re: (ITS#6251) GnuTLS cipher suite failure
by hyc＠symas.com 12 Aug '09

12 Aug '09

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.17 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541256 > > OpenLDAP+gnutls worked fine for me for more than a year, but now I have > TLS problems again. It started on my unstable client when libnss-ldap > reported: > > TLS: could not set cipher list TLS_RSA_AES_256_CBC_SHA1 > > Then I upgraded gnutls and ldap on my server from lenny to unstable and > now even slapd doesn't start: > > TLS: could not set cipher list TLS_RSA_AES_256_CBC_SHA1. > main: TLS init def ctx failed: -1 > > If I comment out line which defines cipher: > > TLSCipherSuite TLS_RSA_AES_256_CBC_SHA1 > > it works again. > > $ gnutls-cli -l|grep TLS_RSA_AES_256_CBC_SHA1 > TLS_RSA_AES_256_CBC_SHA1 0x00, 0x35 SSL3.0 > > ...so I don't see why it shouldn't work. This appears to be caused by our switch to using GnuTLS's cipher suite parsing functions in 2.4.14 (due to ITS#5887). The syntax that GnuTLS uses is quite different from what we were using in 2.4.13 and earlier. Also, the GnuTLS documentation on their format is misleading and just plain wrong on several points. We can treat this as an OpenLDAP doc bug, or we can revert to the pre-ITS#5887 behavior, which still works as expected. (But then we will be incompatible with the behavior described in the current GnuTLS documentation. But of course, the doc is wrong anyway.) For reference, the GnuTLS doc says you can list suite names in a semicolon separated list, and they may optionally be prefixed with "+" or "-" to add or remove particular elements from the list. In fact, the list must be colon separated, and the "+" is required. Just listing the name will cause an error. Also, the actual suite names cannot be used, only the individual algorithm names are recognized. So instead of the suite name "TLS_RSA_AES_256_CBC_SHA1" you must specify "+AES-256-CBC:+SHA1". This method is more error-prone, because it makes it possible to specify a list of algorithms that do not conform to any valid suite. All in all, it may be best to revert back to using our own suite parser and ignore the one GnuTLS provides. -- -- 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#6215) liblber problems
by h.b.furuseth＠usit.uio.no 12 Aug '09

12 Aug '09

Kurt(a)OpenLDAP.org writes: >On Aug 7, 2009, at 11:16 AM, h.b.furuseth(a)usit.uio.no wrote: > >>> - decode.c is quite lax about what it accepts. Should we tighten >>> that when feasible, or remain "liberal in what we accept"? > > Decoding needs to be liberal here. Otherwise interoperability will > suffer as it is well established that there exists many > implementations which are not strict in what they send. OK. ITS done, then. -- Hallvard

1 0

(ITS#6247)
by daniel＠pluta.biz 12 Aug '09

12 Aug '09

Hi, I've just uploaded an updated version. Changes regarding schema: - Added EQ-Matching rule to both nowNot{Before|After} attributes - changed attribute nowNotAfter from single- into multi-value ftp://ftp.openldap.org/incoming/daniel-pluta-now-090812.tgz Best regards Daniel

1 0

(ITS#6251) GnuTLS cipher suite failure
by quanah＠zimbra.com 12 Aug '09

12 Aug '09

Full_Name: Quanah Gibson-Mount Version: 2.4.17 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541256 OpenLDAP+gnutls worked fine for me for more than a year, but now I have TLS problems again. It started on my unstable client when libnss-ldap reported: TLS: could not set cipher list TLS_RSA_AES_256_CBC_SHA1 Then I upgraded gnutls and ldap on my server from lenny to unstable and now even slapd doesn't start: TLS: could not set cipher list TLS_RSA_AES_256_CBC_SHA1. main: TLS init def ctx failed: -1 If I comment out line which defines cipher: TLSCipherSuite TLS_RSA_AES_256_CBC_SHA1 it works again. $ gnutls-cli -l|grep TLS_RSA_AES_256_CBC_SHA1 TLS_RSA_AES_256_CBC_SHA1 0x00, 0x35 SSL3.0 ...so I don't see why it shouldn't work.

1 0

Re: (ITS#6248) Support multiple CA Cert directories
by hyc＠symas.com 11 Aug '09

11 Aug '09

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.x > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > Both openssl and gnutls support loading CA certs from multiple directories. It > would be handy to be able to do this for slapd and the ldap clients. For > example, zimbra puts its CA certs in /opt/zimbra/conf/ca, but the system it is > installed upon is going to have a different default destination for where its > ldap clients look for CA certs. By having support for the multiple paths, the > configuration can be adjusted to look in both the system location, and any > number of specialized ones. > In light of ITS#5582, this should probably wait until 2.5. I.e., we probably also want to require the OpenSSL default paths to be explicitly enabled when we allow multiple paths to be configured. E.g. we could allow "DEFAULT" to be a specially recognized token for enabling the default path. -- -- 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#6249) Feature request: Password Modify ext. op. and anonymous LDAP connection
by Kurt＠OpenLDAP.org 11 Aug '09

11 Aug '09

RFC 3062 specifically says: This operation SHALL NOT be used anonymously. -- Kurt

1 0

Re: (ITS#6249) Feature request: Password Modify ext. op. and anonymous LDAP connection
by hyc＠symas.com 11 Aug '09

11 Aug '09

Michael Ströder wrote: > hyc(a)symas.com wrote: >> Michael Ströder wrote: >>> hyc(a)symas.com wrote: >>>> michael(a)stroeder.com wrote: >>>>> Full_Name: Michael Ströder >>>>> Version: HEAD >>>>> OS: >>>>> URL: >>>>> Submission from: (NULL) (84.163.50.194) >>>>> >>>>> I'd like to request that a Password Modify ext. op. request should succeed on a >>>>> LDAP connection as anonymous if the LDAP client provides the correct old >>>>> password. >>>>> >>>>> E.g. OpenDS implements it like this and it makes sense to me regarding a user >>>>> setting a new password in case of an expired password. >>>> Adding this feature would open up the pwdModify exop as a mechanism for >>>> password guessing attacks. >>> There could be still the bad password counter in effect just like when >>> processing bind requests. >> >> But there is no corresponding lockout action to take when a maxfailure limit >> is reached. I.e., it is impossible to lockout "anonymous". You thus open a >> security hole that cannot be closed. > > The password modify ext.op. request contains the DN (or username) of the entry > to which the old password belongs. > > Since the old password is really checked you could apply the lockout to the > entry for which the password is going to be changed. (It fails with Server is > "unwilling to perform: unwilling to verify old password." even if the user is > bound on that connection.) You're still not thinking this through. One of the basic principles of security design is to reduce the number of possible attack surfaces. You are deliberately opening up a new attack vector with no real benefit. Since grace logins are already supported, your proposal doesn't benefit any real users. It only benefits potential attackers. Closing this ITS. -- -- 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#6250) Password modify ext.op. - automagically add simpleSecurityObject
by hyc＠symas.com 11 Aug '09

11 Aug '09

michael(a)stroeder.com wrote: > Howard Chu wrote: >> Michael Ströder wrote: >>> Let's assume the policy for a deployment is that password changes MUST be >>> applied by using password modify ext. op. (e.g. because smbk5pwd is >>> used or >>> similar) and you want to use object class 'account' for user entries. How >>> could the attribute 'userPassword' be added to the user entry then? >>> It's kind >>> of a dead-lock situation. >> >> Then you made a mistake in your data design. > > Nope. Since with a modify request I can achieve the goal by adding object > class 'simpleSecurityObject'. IMO password modify ext.op. should result in > userPassword being added. One could view it as a hen-and-egg problem because > 'simpleSecurityObject' is mandating 'userPassword'. Since the ppolicy overlay already provides the facility for hashing plaintext passwords on Add and Modify, there's no reason you couldn't have just created the objects correctly in the first place. >> You should have chosen an >> objectclass (or set of objectclasses) that supports authentication from >> the outset. To me this is analogous to the usual prohibition against >> changing an object's structural class - you cannot change a car into a >> pencil. You cannot change a non-user into a user. > > Please don't compare apples with pies. It was an analogy, not a literal comparison. Don't lose the main point, which is that changing a non-user into a user is a significant change in the purpose of an object. -- -- 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#6250) Password modify ext.op. - automagically add simpleSecurityObject
by michael＠stroeder.com 11 Aug '09

11 Aug '09

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs