Re: (ITS#4942) configurable filter blocking
by h.b.furuseth＠usit.uio.no
quanah(a)OpenLDAP.org writes:
> For example, I may want to block subfinal indices on the
> "suAffiliation" attribute in the cn=people,dc=stanford,dc=edu tree.
I should have added: Unless you've got a better answer than me for
why this is better than the "unchecked" limit, it might be more
useful to block "suAffiliation" from getting a "subfinal" index.
Then use the "unchecked" limit to block too general searches.
--
Regards,
Hallvard
16 years, 4 months
Re: (ITS#4942) configurable filter blocking
by h.b.furuseth＠usit.uio.no
quanah(a)OpenLDAP.org writes:
> In reading through the documentation for Fedora DS, I saw an
> interesting feature where you can, at the slapd level, disable the
> ability for clients to execute filters when the attribute(s) being
> filtered on are not indexed.
What's the motivation for this? I've thought about suggesting similar
features (or maybe even suggested it, I don't remember) - but so far
the "unchecked" limit has proved a better way for my purposes.
How does it work with complex filters? E.g. (&(cn=foo)(mail=*))
where cn is indexed and finds the relevant entries, mail=*
eliminates the 0.1% mailless users. Should this succeed if mail
has no presence index? If no, what's the advantage of forbidding
it? If yes, how do you stop (&(objectClass=person)(mail=*))?
> This seems an interesting feature to me, but I think it could be
> more worthwhile to make it a bit more configurable, (...)
> For example, I may want to block subfinal indices on the
> "suAffiliation" attribute in the cn=people,dc=stanford,dc=edu tree.
I can see an access control reason for doing that, though users
might get trivially around it by appending a '*' to the filter.
And I do use sizelimit and the "unchecked" limit as a crude form of
access control, as well as to ensure a good response time. But it
remains crude, since it's not what an index is for - it's basically
just an optimization.
--
Regards,
Hallvard
16 years, 4 months
Re: (ITS#4941) incorrect description of TLS_REQCERT setting
by guenther＠sendmail.com
On Mon, 30 Apr 2007, Howard Chu wrote:
> guenther+ldapdev(a)sendmail.com wrote:
...
>> - 'allow' checks the identity of the server vs its cert (per RFC 4513,
>> section 3.1.3) and will terminate the connection if they don't match
>> - 'try' is the same as 'demand' and 'hard'
>
> Not quite. With both "allow" and "try" it's OK if the server provides no
> certificate.
That's true of 'demand' and 'hard' as well. The only difference between
'try' and 'demand' in the code is that the latter passes
SSL_CTX_set_verify() the SSL_VERIFY_FAIL_IF_NO_PEER_CERT flag, but that
flag has NO EFFECT on SSL clients. This is documented on the
SSL_CTX_set_verify() manpage and confirmed by grepping the openssl source
for it.
If you don't believe me, I suggest you try configuring your server to
accept the ADH suites (don't forget to set TLSDHParamFile to /dev/null)
and give ldapsearch a whirl with
LDAPTLS_REQCERT=hard
LDAPTLS_CIPHER_SUITE=ADH-AES256-SHA
in your environment. That's what I did.
Philip Guenther
16 years, 4 months
(ITS#4942) configurable filter blocking
by quanah＠OpenLDAP.org
Full_Name: Quanah Gibson-Mount
Version: NA
OS: NA
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (171.66.155.86)
In reading through the documentation for Fedora DS, I saw an interesting feature
where you can, at the slapd level, disable the ability for clients to execute
filters when the attribute(s) being filtered on are not indexed. This seems an
interesting feature to me, but I think it could be more worthwhile to make it a
bit more configurable, where you could block certain filter types from being
used, regardless of whether or not they were indexed, and expanded to only
pertain to particular subtrees.
For example, I may want to block subfinal indices on the "suAffiliation"
attribute in the cn=people,dc=stanford,dc=edu tree.
Just food for thought.
--Quanah
16 years, 4 months
Re: (ITS#4941) incorrect description of TLS_REQCERT setting
by hyc＠symas.com
guenther+ldapdev(a)sendmail.com wrote:
> Full_Name: Philip Guenther
> Version: 2.3.27
> OS: linux and solaris
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (64.58.1.252)
>
>
> The description of the TLS_REQCERT setting in the ldap.conf(5) manpage does not
> match the actual operation of the code. In particular:
> - clients don't 'request' server certs in TLS. They get one if the cipher
> suite
> uses them, otherwise they don't
> - 'allow' checks the identity of the server vs its cert (per RFC 4513,
> section 3.1.3) and will terminate the connection if they don't match
> - 'try' is the same as 'demand' and 'hard'
Not quite. With both "allow" and "try" it's OK if the server provides no
certificate. The difference is, with "try", if a cert is provided, it
must be valid.
>
>
> Here's a possible patch to ldap.conf.5 to fix the above. A reference to the RFC
> should perhaps be added to the text. I was also tempted to add a sentence to
> the lead-in to clarify that the setting has no effect if the negotiated cipher
> suite doesn't use certs, as a clarification of the "if any" in the existing
> lead-in, but that's minor. Simply having an even slightly correct description
> of 'allow' is the important thing.
>
> --- ldap.conf.5 26 Jan 2006 05:57:49 -0000
> +++ ldap.conf.5 30 Apr 2007 08:39:53 -0000
> @@ -249,22 +249,20 @@
> .RS
> .TP
> .B never
> -The client will not request or check any server certificate.
> +The client will not check the server certificate at all.
> .TP
> .B allow
> -The server certificate is requested. If no certificate is provided,
> -the session proceeds normally. If a bad certificate is provided, it will
> -be ignored and the session proceeds normally.
> -.TP
> -.B try
> -The server certificate is requested. If no certificate is provided,
> -the session proceeds normally. If a bad certificate is provided,
> +The client will only verify that name used to connect to the server
> +matches one of the server certificate's subjectAltName or CN values.
> +If no match is found, the session is immediately terminated.
> +.TP
> +.B try | demand | hard
> +These keywords are equivalent.
> +The client will verify the server certificate is valid and matches the
> +name used to connect (as for 'allow').
> +If a bad or mismatched certificate is provided,
> the session is immediately terminated.
> -.TP
> -.B demand | hard
> -These keywords are equivalent. The server certificate is requested. If no
> -certificate is provided, or a bad certificate is provided, the session
> -is immediately terminated. This is the default setting.
> +This is the default setting.
> .RE
> .TP
> .B TLS_CRLCHECK <level>
>
>
>
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
16 years, 4 months
(ITS#4941) incorrect description of TLS_REQCERT setting
by guenther+ldapdev＠sendmail.com
Full_Name: Philip Guenther
Version: 2.3.27
OS: linux and solaris
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (64.58.1.252)
The description of the TLS_REQCERT setting in the ldap.conf(5) manpage does not
match the actual operation of the code. In particular:
- clients don't 'request' server certs in TLS. They get one if the cipher
suite
uses them, otherwise they don't
- 'allow' checks the identity of the server vs its cert (per RFC 4513,
section 3.1.3) and will terminate the connection if they don't match
- 'try' is the same as 'demand' and 'hard'
Here's a possible patch to ldap.conf.5 to fix the above. A reference to the RFC
should perhaps be added to the text. I was also tempted to add a sentence to
the lead-in to clarify that the setting has no effect if the negotiated cipher
suite doesn't use certs, as a clarification of the "if any" in the existing
lead-in, but that's minor. Simply having an even slightly correct description
of 'allow' is the important thing.
--- ldap.conf.5 26 Jan 2006 05:57:49 -0000
+++ ldap.conf.5 30 Apr 2007 08:39:53 -0000
@@ -249,22 +249,20 @@
.RS
.TP
.B never
-The client will not request or check any server certificate.
+The client will not check the server certificate at all.
.TP
.B allow
-The server certificate is requested. If no certificate is provided,
-the session proceeds normally. If a bad certificate is provided, it will
-be ignored and the session proceeds normally.
-.TP
-.B try
-The server certificate is requested. If no certificate is provided,
-the session proceeds normally. If a bad certificate is provided,
+The client will only verify that name used to connect to the server
+matches one of the server certificate's subjectAltName or CN values.
+If no match is found, the session is immediately terminated.
+.TP
+.B try | demand | hard
+These keywords are equivalent.
+The client will verify the server certificate is valid and matches the
+name used to connect (as for 'allow').
+If a bad or mismatched certificate is provided,
the session is immediately terminated.
-.TP
-.B demand | hard
-These keywords are equivalent. The server certificate is requested. If no
-certificate is provided, or a bad certificate is provided, the session
-is immediately terminated. This is the default setting.
+This is the default setting.
.RE
.TP
.B TLS_CRLCHECK <level>
16 years, 4 months
(ITS#4940) libldap doesn't wait for server's TLS close_notify
by guenther+ldapdev＠sendmail.com
Full_Name: Philip Guenther
Version: 2.3.27
OS: Linux and Solaris
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (64.58.1.252)
[I vaguely recall seeing a report of this issue in the archives of one of the
mailing lists, but I can no longer find the original.]
If you trace the packets sent when you use, for example, ldapsearch against a
server on a different host, using either the -Z option to do TLS or using an
ldaps URI, you'll discover that the TCP connection is actually reset instead of
being closed cleanly: the client sends TCP RSTs in response to the server's
final packets.
This is because libldap uses the following sequence when unbind a TLS or SSL
connection:
1) send the unbind request (over the TLS or SSL layer)
2) call SSL_shutdown(), sending the TLS close_notify alert
3) call close()
After receiving the close_notify alert from step (2), the server sends back its
own close_notify alert and then calls close(). However, because the client
didn't wait for the server's response before calling close() on its end, the
client's TCP stack considers the TCP connection to already be gone and responds
with the RST packets. This occurs with Linux and Solaris clients and probably
most other unices: the response to packets after a close() doesn't vary in my
experience.
There are a number of ways this can be handled:
1) change the client to wait until it sees the server's close_notify alert by
replacing "SSL_shutdown( p->ssl );" in tls.c with the two lines:
if (SSL_shutdown( p->ssl ) == 0)
SSL_shutdown( p->ssl );
(I have confirmed that this works. As documented, the first call will return
1
if the server's close_notify has already been received, if not, the second
call
will block until it is received.)
2) change the client to not bother to send a close_notify alert when it's just
going to close() the connection; change the server to not send a
close_notify
if it didn't get one. This probably violates the TLS spec, but the fact
that
TLS/1.1 permits resumption of sessions without close_notify having been sent
indicates that the violation is not a major issue, particularly given that
LDAP's
unbind request prevents truncation attacks. Close_notifies are, of course,
required if the client just wants to terminate the TLS layer and resume
unprotected LDAP operations.
3) ignore the issue: it only causes one or two extra packets to be sent. While
it
also eliminates the TIME_WAIT state, LDAP's application-level close (the
unbind
request) means it doesn't need reliable full-duplex closure, so the only
concern
would be random connection issues from reincarnations of the TCP tuple,
which
is unlikely for an LDAP connection.
Personally, I like the simplicity and cleanliness of solution (1).
16 years, 4 months
Re: (ITS#4938) hdb_db_close SEGVs
by quanah＠zimbra.com
----- quanah(a)zimbra.com wrote:
> ----- richton(a)nbcs.rutgers.edu wrote:
> > I don't have #5 (sleepycat#14657) nor the unofficial
> >
> http://www.stanford.edu/services/directory/openldap/configuration/patches...
> >
> > patch. As for the official one, I'm not sure about its relevance to
> > the
> > actual SEGV due to the "recovery...fail" comment. In other words,
> > though
> > it may be impacting the ability of alock/db_recover to do its thing,
>
> > that's just a side effect of the unclean shutdown which is the real
> > bug
> > here to my view.
>
>
>
>
> Patch #5 specifically deals with a race condition where a checkpoint
> is occuring while a cache buffer retrieval is also occuring causing a
> database corruption that will later not be recoverable from. At
> least, that's how I read sleepcat's description:
>
> 5. Fix a bug where cache buffer retrieval could race with a checkpoint
> call, potentially causing database environment recovery to fail.
> [#14657]
>
> Given that OpenLDAP checkpoints on shutdown, shutting down the server
> could be what is triggering the issue for you. I'd suggest applying
> the patch and seeing if this resolves your problem.
Just to note, I shut down one of my 2.3.35 servers that's served out over 1 million connections since I brought it up, and everything was clean on both shutdown and startup.
--Quanah
16 years, 5 months
Re: (ITS#4938) hdb_db_close SEGVs
by quanah＠zimbra.com
----- richton(a)nbcs.rutgers.edu wrote:
> I don't have #5 (sleepycat#14657) nor the unofficial
> http://www.stanford.edu/services/directory/openldap/configuration/patches...
>
> patch. As for the official one, I'm not sure about its relevance to
> the
> actual SEGV due to the "recovery...fail" comment. In other words,
> though
> it may be impacting the ability of alock/db_recover to do its thing,
> that's just a side effect of the unclean shutdown which is the real
> bug
> here to my view.
Patch #5 specifically deals with a race condition where a checkpoint is occuring while a cache buffer retrieval is also occuring causing a database corruption that will later not be recoverable from. At least, that's how I read sleepcat's description:
5. Fix a bug where cache buffer retrieval could race with a checkpoint call, potentially causing database environment recovery to fail. [#14657]
Given that OpenLDAP checkpoints on shutdown, shutting down the server could be what is triggering the issue for you. I'd suggest applying the patch and seeing if this resolves your problem.
> The region size patch is interesting, but I will tell you that the
> database in question has
>
> set_cachesize 0 200000000 0
>
> and it (to a glance) looks like that only impacts the gig column,
> which I
> have as zero anyway.
Yeah, the patch may not apply for you (I have a 3.5GB cache, so it does for me). Wouldn't harm anything, of course, if you decided later you needed a larger BDB cache. ;)
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
16 years, 5 months
