client StartTLS issue and return codes enhancement
by Jan Vcelak
Hello everyone,
I'm trying to fix one of the OpenLDAP bugs which was reported to Red Hat
bugzilla [1]. But I'm not very sure about the correct behavior of client tools
'-Z' option. In addition, this is closely related to one enhancement, we would
like to propose.
Manual page says:
> -Z[Z] Issue StartTLS (Transport Layer Security) extended operation. If you
> use -ZZ, the command will require the operation to be successful.
According to my findings, -Z option causes that StartTLS request is sent as
a first operation. And then:
1.) If everything goes well, the client and server will communicate securely.
2.) If the TLS connection is established but the certificate verification is
unsuccessful (e.g. hostname doesn't match), the error message is emitted and
the communication continues over the TLS channel.
3.) If the server doesn't support TLS (or is configured not to use TLS),
StartTLS request is rejected and communication is held insecurely.
4.) If client's TLS configuration is wrong (e.g. TLS_CACERT does not exist),
the client connection will fail with 'Can't contact LDAP server (-1)'.
The situation we are dealing with is the 4th option. Is this an expected
behavior? The problem is, that StartTLS request is sent before processing the
certificates. If the server accepts the request, it expects that all following
communication is encrypted. But the client cannot process the certificates,
ignores the TLS failure and sends the following next unencrypted. The server
doesn't understand it, which leads to mentioned error code.
The behavior is the same for OpenSSL and Mozilla NSS. And if it is incorrect,
there at least two possibilities of fixing it, citing from the bug report:
On 2011-05-23 18:09 Rich Megginson wrote:
> On 2011-05-23 17:30 Jan Vcelak wrote:
>
> > 1.) Initialize client certificates before sending StartTLS request.
>
> I think we would have to change the StartTLS protocol to handle this case.
>
> > 2.) Close the TLS connection and establish a new unencrypted one when
> > this situation happens.
>
> This is the safest way to go, but I don't know what impact this would have
> on existing clients.
What do you think about that? Is that expected? Are there a better ways of
solving this?
If this is an expected behavior, the manual pages should probably mention it.
Anyway it would be great, if we could resolve the situation, where the
connection to the server fails due to connection error and due to invalid TLS
configuration. At the API level and maybe as a return code of the client
tools. What do you think about this enhancement?
Thank you.
Jan
[1] https://bugzilla.redhat.com/show_bug.cgi?id=693470
12 years, 6 months
pcache entry ttl handling
by Ralf Haferkamp
Hi,
while working on some issues in slapo-pcache (ITS#6950, 6951, 6953 and
6954). I noticed some (IMO) odd behaviour in how the experiation of
cached queries is handled.
It seems that pcache happily returns entries for cached queries from the
cache even if the query has already expired (ttl is over). It only stops
returning results for such a cached query after the periodic consistency
checker has run an removed those expired queries.
If this is really the desired behaviour I think we should clarify this in
the man-page. If it's not we should fix the code.
--
Ralf
12 years, 6 months
OpenLDAP / Oracle LDAP: naming collision for ldap_set_option/ldap_get_option
by Peter Steiert
Hello alltogether,
i'm not quite sure whether this list is the correct place to discuss the
following topic but I hope so.
I recently had an issue after compiling and running freeradius with
oracle and openldap support.
The error is as following:
Thu May 12 10:06:42 2011 : Debug: [ldap] (re)connect to
ldaps.localnet.local:636, authentication 0
Thu May 12 10:06:42 2011 : Error: [ldap] Could not set
LDAP_OPT_NETWORK_TIMEOUT 1: Bad parameter to an ldap routine
Thu May 12 10:06:42 2011 : Debug: [ldap] setting TLS mode to 1
Thu May 12 10:06:42 2011 : Error: [ldap] could not set LDAP_OPT_X_TLS
option Bad parameter to an ldap routine:
Thu May 12 10:06:42 2011 : Debug: [ldap] bind as cn=RADIUSADMIN,
c=DE/PASSWORD to ldaps.localnet.local:636
Thu May 12 10:06:42 2011 : Debug: [ldap] waiting for bind result ...
Thu May 12 10:06:42 2011 : Debug: [ldap] ldap_result()
Thu May 12 10:06:42 2011 : Error: [ldap] cn=RADIUSADMIN, c=DE bind to
ldaps.localnet.local:636 failed: Can't contact LDAP server
sgslufread: Hard error on read, OS error = 32
sgslufread: Hard error on read, OS error = 32
After longer investigation i found out that the routines:
ldap_set_option
ldap_get_option
are defined in OpenLDAP/ldap.h as well as in Oracle/ldap.h
and are locatable in Oraclelib/libclntsh.so.11.1 as well as in
OpenLDAP/libldap_r.so.
So the ld-loader is sometimes offering the oracle code to the client and
sometime the openldap code. This causes failure in the application.
Now my question to the community here:
Is there a global naming definiton about these routines to avoid such a
conflict?
Wouldn't it be better if Oracle would use it's own namespace convention
as well as OpenLDAP?
Kind regards
Peter
If the list is wrong please tell me the correct one to discuss this topic.
Btw: We did a workaround by using the LD_PRELOAD path :)
12 years, 6 months
replicate internal operations (was: (ITS#6915) memberof+accesslog duplicate reqStart)
by Michael Ströder
Taking this to -devel for clarification.
hyc(a)symas.com wrote:
> The original design for memberOf was for the internal modifications to not be
> replicated. Instead, any replicas that wanted to maintain member information
> was expected to run an identical memberOf overlay configuration.
Ok.
> In general it's incorrect to replicate internal operations. The fanout from
> replicating every internal operation would be too large and the information
> content of what is being replicated is essentially nil. When the servers are
> configured identically they will maintain identical data by virtue of the
> overlays on each node performing the same internal operations in response to a
> given sequence of user operations.
While I agree here I think "internal operations" has to be defined a little
bit more clear: What about extended operations which may result in several
write operations? Extended operations are not written to the accesslog-DB and
are not replicated.
Ciao, Michael.
12 years, 6 months
Critical client controls stop ldap_unbind()
by Hallvard B Furuseth
ldap_unbind() & co fail without doing anything if a critical client
control is set with ldap_set_option() or passed to ldap_unbind_ext_s().
This seems wrong, since ldap_unbind() has always been documented as the
way to both close the connection and free the LDAP structure.
Yet if some code does set a critical client control, that might be a
hack to get exactly this functionality: Temporarily protect the LDAP*
from being destroyed by some other code.
Server controls do not prevent the Unbind. RFC 4511 says the
criticality field MUST be ignored for Unbind controls. But that's
in the protocol. Client controls are an LDAP API invention.
I don't know which solution to pick. Opinions?
Maybe we should deprecate ldap_unbind... calls now that we
have ldap_destroy(). That function also sends an Unbind if it can.
But that doesn't affect existing code using ldap_unbind...().
LDAPControl ctrl = {"1.2.3.4", {0,""}, 1}, *ctrls[] = {&ctrl, NULL};
LDAP *ld = ldap_open("ldap", LDAP_PORT);
ldap_set_option(ld, LDAP_OPT_CLIENT_CONTROLS, ctrls);
ldap_unbind_ext_s(ld, NULL, NULL);
/* Connection remains open here... */
sleep(999);
--
Hallvard
12 years, 7 months
sizelimit and pagedResultsControl - AD vs Openldap ...
by Mads Freek Petersen
Hi all
I have written a simple pure php ldap library to be able to use the pagedResultsControl - which the standard php library - to my knowledge - doesn't support.
Testing it against Openldap and AD i have found that given:
a dit with 1000 objects
a sizelimit of 500
a pagesize of 100
Openldap returns 5 pages of 100 objects while AD returns 10 pages of 100 objects. Ie. if the sizelimit is greater than the pagesize AD ignores it.
What is the correct behavior?
Bwt.hHas anyone ever looked at the "cookie" AD returns - it is more than 1K bytes long!
Regards Mads Freek
------------------------------------------------------
Mads Freek Petersen
Special Consultant
Computer Science Department
Roskilde University
Building 42-1, P.O. Box 260, DK-4000 Roskilde, Denmark
Phone: +45 4674 3882
Fax: +45 4674 3072
E-mail: freek(a)ruc.dk
There are two types of code.
A large pile of crap code, and a small pile of crap code.
Favour the small.
- unknown IBM engineer
12 years, 7 months
.git* files in .tar.gz releases?
by Hallvard B Furuseth
Should .gitattributes and .gitignore be included in releases?
If not, .gitattributes needs the lines:
.gitignore export-ignore
.gitattributes export-ignore
--
Hallvard
12 years, 7 months
Static Analysis of OpenLDAP
by Lynn Gayowski
Klocwork's open source program did some source code analysis for
OpenLDAP a few years back. We've analyzed the project again using our
static analysis product, Klocwork Insight, and found some bugs and
potential security vulnerabilities that may be of interest. The results
are hosted on a secure web portal so only contributors to the project
will have access to the results. They will not be published. Please
email opensource at klocwork dot com for the login credentials.
Issue Summary:
https://opensource.klocwork.com/review/insight-review.html#reportviewer_
goto:project=openldap,report=6,scope=1
Full Details/Issue Management: http://goo.gl/9GNiu
This program will be offered free to open source projects on an ongoing
basis, so if you find the results of value we could analyze future
versions of your project as well.
Cheers,
Lynn Gayowski
Klocwork
P +1.613. 836.8899 ext. 424
lynn.gayowski at klocwork.com
12 years, 7 months
