Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Quanah Gibson-Mount]

--On Sunday, July 21, 2019 10:54 PM +0200 Ondřej Kuzník 
 wrote:



On Sun, Jul 21, 2019 at 10:18:37AM -0700, Quanah Gibson-Mount wrote:

Now you are providing conflicting answers.  The man page for back-ldap
makes zero reference to ldap.conf(5).  It only mentions slapd.conf(5).
The syncrepl section of slapd.conf(5)/slapd-config(5) only mention the
network-timeout value being pulled in from ldap.conf(5).  So which is
it? Do they follow the man page behaviors (which would mean no
ldap.conf(5) for slapd-ldap, and only network-timeout for syncrepl), or
do they violate the man page description?


(replying to the gist of the entire thread)

I'm happy with back-ldap, etc. honouring global ldap.conf. Deployments
that need to avoid that can and should define LDAPNOINIT. Also AFAIK
libldap initialisation happens before any configuration is even parsed
so might be a bit harder to avoid it.


Generally, it seems to me we at the least have a documentation bug, in
that back-ldap(5) and the syncrepl section of
slapd.conf(5)/slapd-config(5) should note that they will rely on
ldap.conf(5) in the absence of TLS (and possibly other paremters) if
they are not found in slapd.conf(5).


We should document what happens somewhere, definitely. Maybe TLS section
of slapd.conf manpage? I'll defer to you where that should happen and
hopefully either of also you wants to write it (and the LDAPNOINIT
advice) while I work on fixing this :) I'll just tweak things later so
the docs fit exactly what happens when it comes to setting up
slapd_tls_ld and what the relevant clients (syncrepl and back-ldap) do
too.


After further discussion with Howard, ITS#8427 is going to get reverted 
from RE24 for now, and we'll look at getting it fixed fully for 2.4.49.  It 
appears it has introduced a regression with both GnuTLS and OpenSSL.  Long 
term, we need to decide exactly how we want this all to work in RE25 as 
well.  I'm with Michael in that I think slapd should never accept any CAs 
unless explicitly configured to do so, and right now it appears that 
without this patch, it can do exactly that with both OpenSSL and GnuTLS, 
regardless of whether or not an ldap.conf file is in place.


--Quanah



--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Quanah Gibson-Mount]

--On Sunday, July 21, 2019 11:16 PM +0100 Howard Chu  wrote:


I take this back. Pretty sure we've had this debate before, haven't found
it in the list archive.

We explicitly create a fresh TLS context in slapd, to eliminate any
ldap.conf initialization defaults.


Ok, so it's GnuTLS that had broken behavior and it was fixed by ITS#8427.

You also noted in IRC that you found the related ITS: 



So GnuTLS actually introduced a regression in behavior.

--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Howard Chu]

Quanah Gibson-Mount wrote:
> --On Sunday, July 21, 2019 10:54 PM +0100 Howard Chu  wrote:

>> Feel free to add a note to slapd.conf(5) / slapd-config(5) about TLS
>> defaults.

I take this back. Pretty sure we've had this debate before, haven't found it in 
the list archive.

We explicitly create a fresh TLS context in slapd, to eliminate any ldap.conf 
initialization defaults.

> I think that's worth doing.



-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Quanah Gibson-Mount]

--On Sunday, July 21, 2019 10:54 PM +0100 Howard Chu  wrote:


You claimed it was inconsistent because syncrepl refers to ldap.conf for
network timeout settings while back-ldap makes no reference to ldap.conf.


No, if you read my email, I was purely noting that again that the man pages 
make no reference to ldap.conf(5) *outside* of syncrepl's explicit 
statement about network-timeout.  Going back to your statement that the 
behavior should conform to the man pages for back-ldap and syncrepl.



Feel free to add a note to slapd.conf(5) / slapd-config(5) about TLS
defaults.


I think that's worth doing.

--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Howard Chu]

Quanah Gibson-Mount wrote:
> --On Sunday, July 21, 2019 10:02 PM +0100 Howard Chu  wrote:
> 
>> As I already said: there is no reason for the syncrepl consumer and
>> back-ldap to behave identically. The manpages are correct in each case.
> 
> I've never said they should behave identically, and I do not fathom why you 
> are so focussed on something I never stated.
> 
> *You* stated:
> 
> "The behavior is supposed to be exactly as specified in the manpages."
> 
> The *man page* for back-ldap makes ZERO reference to ldap.conf.  It makes 
> ZERO reference to back-ldap being considered an "ldap client".  If your 
> statement that
> they should behave as specified in the man pages is true, then its behavior 
> is incorrect, because PER THE MAN PAGE the TLS settings are either EXPLICIT 
> in the
> back-ldap configuration OR they are taking from slapd's TLS settings.  
> NOWHERE does it say that if there are no settings in back-ldap OR slapd that 
> it will THEN
> take the settings from ldap.conf.
> 
> The *exact same* applies to syncrepl and its TLS settings.

You claimed it was inconsistent because syncrepl refers to ldap.conf for 
network timeout settings while
back-ldap makes no reference to ldap.conf.

Clearly there is no requirement for syncrepl and back-ldap to behave 
identically here.

For the TLS settings, as already noted, libldap always reads ldap.conf unless 
you set the NOINIT
env var. All of the slapd TLS settings are set in a TLS context that is 
retrieved from an LDAP*
handle created specifically for this purpose. Naturally this handle inherits 
whatever defaults
libldap picks up. Even so, you are expected to completely configure TLS 
settings in slapd's
configuration, and not rely on any other defaults.

Feel free to add a note to slapd.conf(5) / slapd-config(5) about TLS defaults.

-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Quanah Gibson-Mount]

--On Sunday, July 21, 2019 10:02 PM +0100 Howard Chu  wrote:


As I already said: there is no reason for the syncrepl consumer and
back-ldap to behave identically. The manpages are correct in each case.


I've never said they should behave identically, and I do not fathom why you 
are so focussed on something I never stated.


*You* stated:

"The behavior is supposed to be exactly as specified in the manpages."

The *man page* for back-ldap makes ZERO reference to ldap.conf.  It makes 
ZERO reference to back-ldap being considered an "ldap client".  If your 
statement that they should behave as specified in the man pages is true, 
then its behavior is incorrect, because PER THE MAN PAGE the TLS settings 
are either EXPLICIT in the back-ldap configuration OR they are taking from 
slapd's TLS settings.  NOWHERE does it say that if there are no settings in 
back-ldap OR slapd that it will THEN take the settings from ldap.conf.


The *exact same* applies to syncrepl and its TLS settings.

--Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Ryan Tandy]

On Sun, Jul 21, 2019 at 10:18:37AM -0700, Quanah Gibson-Mount wrote:
Generally, it seems to me we at the least have a documentation bug, in 
that back-ldap(5) and the syncrepl section of 
slapd.conf(5)/slapd-config(5) should note that they will rely on 
ldap.conf(5) in the absence of TLS (and possibly other paremters) if 
they are not found in slapd.conf(5).


For syncrepl at least I understood it was intentional that ldap.conf is 
ignored (since 1cc1f9b). No idea about back-ldap; personally I always 
assumed they were supposed to behave the same.

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Howard Chu]

Quanah Gibson-Mount wrote:
> --On Sunday, July 21, 2019 3:37 PM +0100 Howard Chu  wrote:
> 
>>> --On Sunday, July 21, 2019 2:51 AM +0100 Howard Chu 
>>> wrote:
>>>
 The behavior is supposed to be exactly as specified in the manpages.

>>>
>> A syncrepl consumer is an LDAP client. A back-ldap backend is an LDAP
>> client.
> 
> 
> Now you are providing conflicting answers.  The man page for back-ldap makes 
> zero reference to ldap.conf(5).  It only mentions slapd.conf(5).  The syncrepl
> section of slapd.conf(5)/slapd-config(5) only mention the network-timeout 
> value being pulled in from ldap.conf(5).  So which is it? Do they follow the 
> man page
> behaviors (which would mean no ldap.conf(5) for slapd-ldap, and only 
> network-timeout for syncrepl), or do they violate the man page description?

As I already said: there is no reason for the syncrepl consumer and back-ldap 
to behave identically. The manpages are correct in each case.

> 
> 
> Generally, it seems to me we at the least have a documentation bug, in that 
> back-ldap(5) and the syncrepl section of slapd.conf(5)/slapd-config(5) should 
> note
> that they will rely on ldap.conf(5) in the absence of TLS (and possibly other 
> paremters) if they are not found in slapd.conf(5).
> 
> Additionaly, what should we do about ITS#8427? It was clearly fixing a valid 
> bug.  Do we revert it?  Do we fix the behavior so it fixes the bug reported, 
> but
> does not introduce a regression?

It sounds like the behavior with OpenSSL is currently correct, and currently 
broken on GnuTLS.
> 
> And we need to know the answer to that and have a fix in rather quickly.
> 
> --Quanah
> 
> 
> -- 
> 
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> 
> 
> 


-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Ondřej Kuzník]

On Sun, Jul 21, 2019 at 10:18:37AM -0700, Quanah Gibson-Mount wrote:
> Now you are providing conflicting answers.  The man page for back-ldap makes
> zero reference to ldap.conf(5).  It only mentions slapd.conf(5).  The
> syncrepl section of slapd.conf(5)/slapd-config(5) only mention the
> network-timeout value being pulled in from ldap.conf(5).  So which is it? Do
> they follow the man page behaviors (which would mean no ldap.conf(5) for
> slapd-ldap, and only network-timeout for syncrepl), or do they violate the
> man page description?

(replying to the gist of the entire thread)

I'm happy with back-ldap, etc. honouring global ldap.conf. Deployments
that need to avoid that can and should define LDAPNOINIT. Also AFAIK
libldap initialisation happens before any configuration is even parsed
so might be a bit harder to avoid it.

> Generally, it seems to me we at the least have a documentation bug, in that
> back-ldap(5) and the syncrepl section of slapd.conf(5)/slapd-config(5)
> should note that they will rely on ldap.conf(5) in the absence of TLS (and
> possibly other paremters) if they are not found in slapd.conf(5).

We should document what happens somewhere, definitely. Maybe TLS section
of slapd.conf manpage? I'll defer to you where that should happen and
hopefully either of also you wants to write it (and the LDAPNOINIT
advice) while I work on fixing this :) I'll just tweak things later so
the docs fit exactly what happens when it comes to setting up
slapd_tls_ld and what the relevant clients (syncrepl and back-ldap) do
too.

> Additionaly, what should we do about ITS#8427? It was clearly fixing a valid
> bug.  Do we revert it?  Do we fix the behavior so it fixes the bug reported,
> but does not introduce a regression?
> 
> And we need to know the answer to that and have a fix in rather quickly.

I'll see tomorrow about reproducing the regression with ldap.conf. If
I'm successful, extending the test case and a fix should not take long.

Thanks,

-- 
Ondřej Kuzník
Senior Software Engineer
Symas Corporation   http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Quanah Gibson-Mount]

--On Sunday, July 21, 2019 3:37 PM +0100 Howard Chu  wrote:


--On Sunday, July 21, 2019 2:51 AM +0100 Howard Chu 
wrote:


The behavior is supposed to be exactly as specified in the manpages.




A syncrepl consumer is an LDAP client. A back-ldap backend is an LDAP
client.



Now you are providing conflicting answers.  The man page for back-ldap 
makes zero reference to ldap.conf(5).  It only mentions slapd.conf(5).  The 
syncrepl section of slapd.conf(5)/slapd-config(5) only mention the 
network-timeout value being pulled in from ldap.conf(5).  So which is it? 
Do they follow the man page behaviors (which would mean no ldap.conf(5) for 
slapd-ldap, and only network-timeout for syncrepl), or do they violate the 
man page description?



Generally, it seems to me we at the least have a documentation bug, in that 
back-ldap(5) and the syncrepl section of slapd.conf(5)/slapd-config(5) 
should note that they will rely on ldap.conf(5) in the absence of TLS (and 
possibly other paremters) if they are not found in slapd.conf(5).


Additionaly, what should we do about ITS#8427? It was clearly fixing a 
valid bug.  Do we revert it?  Do we fix the behavior so it fixes the bug 
reported, but does not introduce a regression?


And we need to know the answer to that and have a fix in rather quickly.

--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Howard Chu]

Quanah Gibson-Mount wrote:
> --On Sunday, July 21, 2019 2:51 AM +0100 Howard Chu  wrote:
> 
>> The behavior is supposed to be exactly as specified in the manpages.
>>
>> There is no reason to expect back-ldap and syncrepl to be exactly alike;
>> they perform different functions.
> 
> You missed the point.  It wasn't about syncrepl vs back-ldap, it was about 
> whether or not *anything* used in slapd should ever pull in data from 
> ldap.conf.  The
> *only* thing I can find that pulls in anything from ldap.conf (per the man 
> pages) is syncrepl.  Which seems rather odd, particularly since it's only for 
> one
> specific value.  Especially given that ldap.conf(5) specifies it is only for 
> ldap clients.

A syncrepl consumer is an LDAP client. A back-ldap backend is an LDAP client.

-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Nikos Voutsinas]

On Sun, Jul 21, 2019 at 1:50 PM Michael Ströder 
wrote:

> On 7/20/19 8:45 PM, Nikos Voutsinas wrote:
> > Weird... My build of OPENLDAP_REL_ENG_2_4_48 on Debian/Buster against
> > openssl was working, without using the olcTLSCACertificateFile.
>
> Why that happens is a good question.
>
> You probably have to dig a bit deeper and examine whether the OpenSSL
> lib initializes a default trust store generated by
> update-ca-certificates (from Debian package ca-certificates) and whether
> your CA cert is present there.
>


Yes, this is  what I suspect too, but that's out of the scope of this list.
It also appears not to be a GNUTLS or OpenSSL issue, thus the above results
are not relevant any more with the specific issue.

On the other hand it is nice that we were able to pinpoint the cause of
problem before the announcement of the release, and start a discussion on
the subject.

Nikos

Nikos

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Michael Ströder]

On 7/20/19 8:45 PM, Nikos Voutsinas wrote:
> Weird... My build of OPENLDAP_REL_ENG_2_4_48 on Debian/Buster against
> openssl was working, without using the olcTLSCACertificateFile.

Why that happens is a good question.

You probably have to dig a bit deeper and examine whether the OpenSSL
lib initializes a default trust store generated by
update-ca-certificates (from Debian package ca-certificates) and whether
your CA cert is present there.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Drop support for GNUTLS and libnss in 2.5?

[Michael Ströder]

On 7/20/19 6:07 PM, Ryan Tandy wrote:
> On Sat, Jul 20, 2019 at 12:13:38PM +0200, Michael Ströder wrote:
>> The question is whether this is still revelavant with OpenSSL 3.0.0
>> moving to Apache-2.0 license [1]. [2] says APL-2.0 is not compatible
>> with GPLv2 though.
> 
> Unfortunately that's correct - the Apache license does not solve the
> issue for binaries containing GPLv2 code without an OpenSSL exception.

How many GPLv2 licensed Debian packages link libldap?

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Michael Ströder]

On 7/21/19 4:32 AM, Quanah Gibson-Mount wrote:
> You missed the point.  It wasn't about syncrepl vs back-ldap, it was
> about whether or not *anything* used in slapd should ever pull in data
> from ldap.conf.

From my understanding up to now ldap.conf was used in back-ldap and
people make use of it. Aside from whether this was a doc or
implementation bug you should seriously consider whether it's worth the
trouble to change back-ldap's behaviour within 2.4.x release series.

Personally I'm in the camp of explicitly specifying (possibly different)
trust anchors for every aspect. Especially since we all should use a
decent config management today it's really easy. So I'd like to propose
a change for 2.5.x that nothing within slapd uses ldap.conf
(LDAPNOINIT=1 for all of slapd's internal stuff).

Also I don't want to use system-wide trust stores by default without
explicitly being configured. But that's another issue.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature