thomaswilliampritchard@gmail.com schrieb am 31.03.2022 um 06:29 in Nachricht
20220331042904.5262.30720@hypatia.openldap.org:
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
- connect to the server
- Send starttls
- 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.