--On Friday, July 07, 2017 6:27 PM +0000 Jon C Kidder <jckidder(a)aep.com>
wrote:
> olcDbStartTLS: ldaps starttls=no
> tls_cacert="/appl/openldap/etc/openldap/tls/cacerts.cer"
> tls_reqcert=demand tls_crlcheck=none
There is no such option as "starttls" for the olcDbStartTLS parameter.
>From the man page:
tls {[try-]start|[try-]propagate|ldaps}
[tls_cert=<file>]
[tls_key=<file>] [tls_cacert=<file>]
[tls_cacertdir=<path>]
[tls_reqcert=never|allow|try|demand]
[tls_cipher_suite=<ciphers>] [tls_crlcheck=none|peer|all]
Specify the use of TLS when a regular connection is
initialized.
The StartTLS extended operation will be used unless the
URI
directive protocol scheme is ldaps://. In that case this
keyword
may only be set to "ldaps" and the StartTLS operation will
not
be used. propagate issues the StartTLS operation only if
the
original connection did. The try- prefix instructs the proxy
to
continue operations if the StartTLS operation failed; its use
is
not recommended.
My guess then is everything past that point is ignored, since you've
provided invalid configuration data.
The attribute is also poorly named, as it may or may not have anything to
do with startTLS. More likely it should have just been called olcDbTLS
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
I am in the process of moving our older existing openldap server
infrastructure that we use to authenticate multiple users to our Linux
infrastructure to use RH5 openldap 2.3 server. The current ldap servers
support starttls and listen on 389 and 636. We want to continue with
this setup. While sniffing traffic using tcpdump and using various
ldapsearch options I noticed that if the client doesn't request starttls
or connect on 636 is is possible to grab a users ldap record and the
transmission is in clear text. If I authenticate to the server using
the -W option to ldapsearch the record is sent with the SSHA encrypted
password. Also in the in the tcpdump stream my password I use to
authenticate to the server is sent in clear text.
I guess this behavior is expected since the server is listening on 389
and it is up to the client to initialize the starttls session, but I was
wondering if there was a way to force the server to only use starttls on
398 and not rely on the the client to set up starttls? One option
would be to only have the server start on 636 and not have it listen on
389, but we would like to keep the same functionality if possible. Am I
missing something obvious? The only option that I see as a possiblity is
the TLSVerifyClient { never | allow | try | demand } in slapd.conf.
But, it's unclear to me if this will provide the desired effect.
HI!
To me this rationale for SMTP submission with implicit TLS seems also
applicable to LDAPS vs. StartTLS:
https://tools.ietf.org/html/rfc8314#appendix-A
So LDAPS should not be considered deprecated. Rather it should be
recommended and the _optional_ use of StartTLS should be strongly
discouraged.
Ciao, Michael.
At risk of beating a dead horse, I'd like to hear considerations on STARTTLS vs LDAPS. I'm also particularly interested if openldap plans to support LDAPS long term or if there's actually a deprecation effort going on around LDAPS where it would one day no longer be supported by openldap.
This seems to be the most comprehensive post discussing the virtue of the two. https://security.stackexchange.com/questions/257749/is-ldaps-or-starttls-mo…
I also found a post in this Archive from 2018 that seems to indicate a change of opinion where LDAPS should be preferred, and not deprecated.
https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/…
Does openldap agree that LDAPS should now be the preferred implementation and STARTLS should be discouraged?
I do not have a security background and there is certainly a lot of room for me to misunderstand, but it seems like STARTTLS leaves the door open for a "tls downgrade attack" where a man in the middle could essentially reply to a client effectively saying start tls is not supported and then the client falls back to non tls communication (which is obviously unfortunate). Even if the backend server is properly not responding to clients until STARTTLS is initiated, the man in the middle could initiate a connection with STARTTLS to the ldap server and be talking plaintext to the client. Is that legitimately possible or am I missing a nuance? If one were to only support clients over LDAPS it seems this would be mitigated?
Thanks for the considerations, looking forward to hearing the expert opinions on the topic.
Is there some way to ensure that a client who connects on port 389 can
do nothing without StartTLS?
Or is it necessary to just disable port 389 and only listen for ldaps:/// ?
That's what can be found in the FAQ on openldap.org:
https://www.openldap.org/faq/data/cache/605.html
I would trust this more then any rumors on any stackxxxx page ;)
Am 30.03.22 um 18:45 schrieb thomaswilliampritchard(a)gmail.com:
> At risk of beating a dead horse, I'd like to hear considerations on STARTTLS vs LDAPS. I'm also particularly interested if openldap plans to support LDAPS long term or if there's actually a deprecation effort going on around LDAPS where it would one day no longer be supported by openldap.
>
> This seems to be the most comprehensive post discussing the virtue of the two. https://security.stackexchange.com/questions/257749/is-ldaps-or-starttls-mo…
> I also found a post in this Archive from 2018 that seems to indicate a change of opinion where LDAPS should be preferred, and not deprecated.
> https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/…
>
> Does openldap agree that LDAPS should now be the preferred implementation and STARTLS should be discouraged?
>
> I do not have a security background and there is certainly a lot of room for me to misunderstand, but it seems like STARTTLS leaves the door open for a "tls downgrade attack" where a man in the middle could essentially reply to a client effectively saying start tls is not supported and then the client falls back to non tls communication (which is obviously unfortunate). Even if the backend server is properly not responding to clients until STARTTLS is initiated, the man in the middle could initiate a connection with STARTTLS to the ldap server and be talking plaintext to the client. Is that legitimately possible or am I missing a nuance? If one were to only support clients over LDAPS it seems this would be mitigated?
>
> Thanks for the considerations, looking forward to hearing the expert opinions on the topic.ml
Thomas, hello..
On 31 Mar 2022, at 5:29, thomaswilliampritchard(a)gmail.com wrote:
>> As to this overall discussion, one of the primary issues with connections
>> over ldap:/// is that there's zero way with simple binds to prevent the
>> bind dn + password being sent in the clear by a client to the server. With
>> ldaps:/// the encryption is set up before the BIND occurs so you don't run
>> this risk.
>
> Is that true? Surely I can
> 1. connect to the server
> 2. Send starttls
> 3. Then bind bind can't I?
> I'm fairly certain I've used LDAP Client operating in that order.
Yes, you _can_ and should do that, and most folk do. The problem here is that, with LDAP+StartTLS, the server can't prevent a client doing it the other way around, and sending the bind credentials before StartTLS. That's bad, from the server's point of view.
Best wishes,
Norman
--
Norman Gray : https://nxg.me.uk
--On Thursday, March 31, 2022 8:11 PM +0200 Geert Hendrickx
<geert(a)hendrickx.be> wrote:
> On Thu, Mar 31, 2022 at 04:29:04 -0000, thomaswilliampritchard(a)gmail.com
> wrote:
>> Quanah Gibson-Mount wrote:
>> > So from that standpoint, I'd personally prefer to see ldaps:///
>> > qualified in an RFC so the standardization argument goes away and
>> > ldaps be noted as the preferred method for sites that require
>> > encryption.
>>
>> I agree there is no technical reason LDAPS would not be better. It
>> should be made standard.
>
>
> There are technical reasons in fact, STARTTLS has (had) implementation
> issues both on client- and server-side: https://nostarttls.secvuln.info/
> Not necessarily in OpenLDAP, but it illustrates why in general, protocols
> wrapped in TLS are now preferedd over STARTTLS. (See also RFC8314 for
> e-mail protocols.)
I was saying there's no flaw in LDAPS that I'm aware of that makes it
inferior to startTLS on a technical level. I think the clear text bind
issue in fact shows that LDAPS is technically superior to startTLS when
encryption is required. The remaining issue is there's no RFC for it. I'd
like to see that addressed. It was brought up before but there's been no
progress on that front that I'm aware of.
--Quanah
Michael Ströder wrote:
> => StartTLS over LDAP is undefined
^^
Hmmpf. An "I" was missing here. So it means: StartTLS over LDAPI is undefined.
Ciao, Michael.
On Mon, 2018-02-12 at 14:30 +0100, Michael Ströder wrote:
> HI!
>
> To me this rationale for SMTP submission with implicit TLS seems also
> applicable to LDAPS vs. StartTLS:
>
> https://tools.ietf.org/html/rfc8314#appendix-A
>
> So LDAPS should not be considered deprecated. Rather it should be
> recommended and the _optional_ use of StartTLS should be strongly
> discouraged.
Yes, I strongly agree with this. I have evidence to this fact and can
provide it if required,
>
> Ciao, Michael.
>
--
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane
