>>> <[email protected]> schrieb am 31.03.2022 um 06:29 in >>> Nachricht <[email protected]>: > Quanah Gibson-Mount wrote: >> --On Wednesday, March 30, 2022 8:28 PM +0200 Stefan Kania >> <stefan(a)kania-online.de> 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.
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 (I can't remember why I put "ssf=0" there; maybe to allow anonymous DLAPv2) Regards, Ulrich > >> >> 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.
