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-mor... 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/m...
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.
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@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-mor... 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/m...
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
On 3/30/22 19:28, Stefan Kania 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 ;)
But in this case it's the other way round. The text in the FAQ-O-MATIC is outdated (and cannot be changed I presume).
In the mean-time the IETF position of this had changed. But nobody updates any LDAP-related IETF standards anymore.
Personally I'm recommending LDAPS over StartTLS ext.op. since ever.
Ciao, Michael.
--On Wednesday, March 30, 2022 8:28 PM +0200 Stefan Kania stefan@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.
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.
--Quanah
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.
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.
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.
On 3/31/22 08:11, Ulrich Windl wrote:
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
You can prevent the bind operation to succeed but the clear-text password was already revealed to network sniffers. Be aware of that.
This does not mean that you shouldn't use this security setting. It's useful because it makes misconfigured systems, only supporting StartTLS ext.op., fail early during integration tests - hopefully before real passwords are used.
Ciao, Michael.
--On Thursday, March 31, 2022 9:11 AM +0200 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
I think the point was that you can bind even when not having started TLS before.
Correct.
I don't know whether this can prevent it: olcSecurity: ssf=0 update_ssf=128 simple_bind=64
There is no way to prevent a client from sending a BIND request to an ldap:/// URI with the DN and password in the clear. Even if you set ssf=1 (server mandates encryption), the most that will happen is that the client will get disconnected, but the DN and password will already have traveled over the network in the clear before the client gets disconnected so anyone sniffing the traffic would have access to it.
--Quanah
Quanah Gibson-Mount quanah@fast-mail.org schrieb am 31.03.2022 um 17:45
in Nachricht <EAAAB9ABE315CDA6FADC9E00@[192.168.1.12]>:
‑‑On Thursday, March 31, 2022 9:11 AM +0200 Ulrich Windl <Ulrich.Windl@rz.uni‑regensburg.de> wrote:
I think the point was that you can bind even when not having started TLS before.
Correct.
I don't know whether this can prevent it: olcSecurity: ssf=0 update_ssf=128 simple_bind=64
There is no way to prevent a client from sending a BIND request to an ldap:/// URI with the DN and password in the clear. Even if you set ssf=1 (server mandates encryption), the most that will happen is that the client will get disconnected, but the DN and password will already have traveled over the network in the clear before the client gets disconnected so anyone
sniffing the traffic would have access to it.
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?
Regards, Ulrich
‑‑Quanah
--On Friday, April 1, 2022 11:59 AM +0200 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
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?
For your first bit, you can set up the server to only accept certain cipher suites which would not allow such a thing to happen.
On the second bit, there is no way to prevent a client that attempts to bind with a dn/password over ldap:/// from sending it in the clear.
Regards, Quanah
On 4/1/22 10:59, Ulrich Windl wrote:
Quanah Gibson-Mount quanah@fast-mail.org schrieb am 31.03.2022 um 17:45
There is no way to prevent a client from sending a BIND request to an ldap:/// URI with the DN and password in the clear. Even if you set ssf=1 (server mandates encryption), the most that will happen is that the client will get disconnected, but the DN and password will already have traveled over the network in the clear before the client gets disconnected so anyone sniffing the traffic would have access to it.
But honestly, you could get the same when setting up SSL incorrectly (using eNULL or RSA-PSK-NULL-SHA).
Yes, but you would have to misconfigure this deliberately since Linux distros ship with rather safe crypto policy defaults.
In opposite to that it's quite likely that StartTLS fails accidently.
Ciao, Michael.
Thomas, hello..
On 31 Mar 2022, at 5:29, thomaswilliampritchard@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
- 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.
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
On Thu, Mar 31, 2022 at 04:29:04 -0000, thomaswilliampritchard@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.)
Geert
--On Thursday, March 31, 2022 8:11 PM +0200 Geert Hendrickx geert@hendrickx.be wrote:
On Thu, Mar 31, 2022 at 04:29:04 -0000, thomaswilliampritchard@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
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.
Michael Ströder wrote:
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.
At this point it could just be an Informational RFC, describing current practice.
Ciao, Michael.
Quanah Gibson-Mount quanah@fast-mail.org schrieb am 30.03.2022 um 19:54
in Nachricht <C8313B172407454CBF061C89@[192.168.1.12]>:
‑‑On Wednesday, March 30, 2022 8:28 PM +0200 Stefan Kania <stefan@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.
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.
So while talking about FAQs, maybe someone add: "How to convert am OpenLDAP STARTLTS configuration to ldaps://?"
‑‑Quanah
--On Thursday, March 31, 2022 9:03 AM +0200 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
So while talking about FAQs, maybe someone add: "How to convert am OpenLDAP STARTLTS configuration to ldaps://?"
Not sure what you're going for here. Steps are basically ensure that ldaps is one of the URIs passed to slapd, and adjust client code to use the ldaps URI instead of ldap URI.
--Quanah
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@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.
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
On Thu, Mar 31, 2022 at 5:40 AM Norman Gray gray@nxg.name wrote:
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@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.
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
What would be the process to modify content on the openldap.org page?
--On Thursday, March 31, 2022 12:16 PM -0400 Braiam braiamp@gmail.com wrote:
What would be the process to modify content on the openldap.org page?
Depends on the content. The main web pages are in the OpenLDAP Web git repository.
--Quanah
openldap-technical@openldap.org
-
Braiam -
Geert Hendrickx -
Howard Chu -
Michael Ströder -
Norman Gray -
Quanah Gibson-Mount -
Stefan Kania -
thomaswilliampritchard＠gmail.com -
Ulrich Windl