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-... 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.or... 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

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 ;)

>> <thomaswilliampritchard(a)gmail.com&gt; schrieb am 31.03.2022 um 06:29 in Nachricht

Quanah Gibson-Mount wrote: > --On Wednesday, March 30, 2022 8:28 PM +0200 Stefan Kania > <stefan(a)kania-online.de&gt; wrote: > > > 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 ;) > Unfortunately, the FAQ is dead weight we want to kill and not maintained in > any way, shape, or form. It's currently provided for historical purposes. > > 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.

> > 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.

I think the point was that you can bind even when not having started TLS before.

I don't know whether this can prevent it: olcSecurity: ssf=0 update_ssf=128 simple_bind=64

But honestly, you could get the same when setting up SSL incorrectly (using eNULL or RSA-PSK-NULL-SHA). Also I think if you require an anonymous bind first, the SSF may prevent sending actual user passwords unencrypted; right?

> 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.

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.)

On 3/31/22 19:15, Quanah Gibson-Mount wrote: > 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. My attempt to resurrect the IETF ldapext WG failed back in 2015. :-/ Well, in fact every LDAP server I've tested supports LDAPS. So at least implementors should not have any objections. So if you're eager to write an individual I-D I'd be willing to review, discuss and support it. But I won't write it.

Ciao, Michael.

So while talking about FAQs, maybe someone add: "How to convert am OpenLDAP STARTLTS configuration to ldaps://?"

Quanah and all, hello. On 30 Mar 2022, at 18:54, Quanah Gibson-Mount wrote: > --On Wednesday, March 30, 2022 8:28 PM +0200 Stefan Kania < stefan(a)kania-online.de&gt; wrote: > >> 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 ;) > > Unfortunately, the FAQ is dead weight we want to kill and not maintained in any way, shape, or form. It's currently provided for historical purposes. Since the copyright dates at the bottom of that page are '1998-2013', so that the content of the site is now nearly a decade out of date, I feel the FAQ-o-matic now has negative utility, and that you should give in to the urge to kill it. I respect and applaud the desire to preserve the content for historical reasons, but surely that goal can be served by making a tarball of the content available at whatever page https://www.openldap.org/faq/.../* were to redirect to (ie, the pages shouldn't be 404-ed, but neither should they be 200; 301 is good). I have previously (indeed recently) looked at that page and, without thinking much about the question, taken its deprecation of LDAPS as current doctrine. And.... ah, FAQ-o-matic I have fond memories of FAQ-o-matics, back when wikis were new... Best wishes, Norman -- Norman Gray : https://nxg.me.uk