I propose increasing the default olcLocalSSF to 128. Mentioned initially on IRC, now bringing it to the list for completeness and archival.
In typical setups people want to require TLS *or* ldapi, and ssf=128 seems like a pretty common olcSecurity setting for current systems.
thanks Ryan
On 07/26/2018 04:47 AM, Ryan Tandy wrote:
I propose increasing the default olcLocalSSF to 128. Mentioned initially on IRC, now bringing it to the list for completeness and archival.
In typical setups people want to require TLS *or* ldapi, and ssf=128 seems like a pretty common olcSecurity setting for current systems.
+1
But why not choosing an even higher value like 256? I really wonder why it was set to 71.
Ciao, Michael.
Am Thu, 26 Jul 2018 08:19:34 +0200 schrieb Michael Ströder michael@stroeder.com:
On 07/26/2018 04:47 AM, Ryan Tandy wrote:
I propose increasing the default olcLocalSSF to 128. Mentioned initially on IRC, now bringing it to the list for completeness and archival.
In typical setups people want to require TLS *or* ldapi, and ssf=128 seems like a pretty common olcSecurity setting for current systems.
+1
But why not choosing an even higher value like 256? I really wonder why it was set to 71.
As Kurt mentioned on 1st. LDAPCon in Cologne, it is higher value than 56 and less than 128.
-Dieter
On 07/26/2018 09:04 AM, Dieter Klünter wrote:
Am Thu, 26 Jul 2018 08:19:34 +0200 schrieb Michael Ströder michael@stroeder.com:
But why not choosing an even higher value like 256? I really wonder why it was set to 71.
As Kurt mentioned on 1st. LDAPCon in Cologne, it is higher value than 56 and less than 128.
But why? What's the technical reason for it?
Ciao, Michael.
On 26. juli 2018 09:04, Dieter Klünter wrote:
Am Thu, 26 Jul 2018 08:19:34 +0200 schrieb Michael Ströder michael@stroeder.com:
On 07/26/2018 04:47 AM, Ryan Tandy wrote:
I propose increasing the default olcLocalSSF to 128. Mentioned initially on IRC, now bringing it to the list for completeness and archival.
In typical setups people want to require TLS *or* ldapi, and ssf=128 seems like a pretty common olcSecurity setting for current systems.
+1
I'd rather leave it alone.
I prefer to leave it alone, except maybe clarify the doc. Currenlty if you want ldapi Bind and you have set ssf, you probably set it high so must also set localssf. If we pick some higher default, then some people who set ssf must also set localssf, others need not.
I were implementing a new LDAP server, I'd pick a higher default. But I'd rather not weaken security defaults in existing software.
But why not choosing an even higher value like 256?
Indeed. However, any particular value will be wrong for someone. Depends on how safe your filesystem setup is and whether it's easier to break in to get at the ldapi socket than it is to just attack slapd.
I really wonder why it was set to 71.
As Kurt mentioned on 1st. LDAPCon in Cologne, it is higher value than 56 and less than 128.
I.e. between DES (56) and "RC4, Blowfish and other modern strong ciphers" (128) described for olcSaslSecProps minssf in man slapd-config. Also lower than triple DES (112).
Maybe a number of people should update their "pretty common olcSecurity setting" of 128:-) I don't know the values for more modern ciphers.
I wrote:
(...) any particular value will be wrong for someone. Depends on how safe your filesystem setup is and whether it's easier to break in to get at the ldapi socket than it is to just attack slapd.
I forgot:
You could forge ldapi: credentials in early OpenLDAP versions, depending on whether the OS provided a safe way to pass user credentials or not. There's some hack in place now for OSes which don't, but I seem to remember I never felt all that trustful of it.
On 07/26/2018 01:38 PM, Hallvard Breien Furuseth wrote:
I wrote:
(...) any particular value will be wrong for someone. Depends on how safe your filesystem setup is and whether it's easier to break in to get at the ldapi socket than it is to just attack slapd.
You could forge ldapi: credentials in early OpenLDAP versions,
Well, but early OpenLDAP releases don't count when talking about defaults for newer releases.
depending on whether the OS provided a safe way to pass user credentials or not. There's some hack in place now for OSes which don't, but I seem to remember I never felt all that trustful of it.
I vaguely remember the discussions about that here. But wasn't that solved by not allowing SASL/EXTERNAL over LDAPI on those platforms?
My memory might not serve me well though...
I heavily rely on SASL/EXTERNAL over LDAPI and peer credential mapping in Æ-DIR to avoid credentials in local client config.
Ciao, Michael.
On 07/26/2018 01:34 PM, Hallvard Breien Furuseth wrote:
On 26. juli 2018 09:04, Dieter Klünter wrote:
Am Thu, 26 Jul 2018 08:19:34 +0200 schrieb Michael Ströder michael@stroeder.com:
I really wonder why it was set to 71.
As Kurt mentioned on 1st. LDAPCon in Cologne, it is higher value than 56 and less than 128.
I.e. between DES (56) and "RC4, Blowfish and other modern strong ciphers" (128) described for olcSaslSecProps minssf in man slapd-config. Also lower than triple DES (112).
Well, the references to 3DES and RC4 shows that the whole SSF concept is broken anyway. No-one would assume RC4 to have SSF=128 anymore.
This is a can of worms. The OpenSSL folks also had to adjust there cipher sets behind the labels HIGH etc. recently. This should be subject of on-going changes.
The CyrusSASL project also sets SSF levels which I'd consider outdated. Well, the project seems pretty much dead anyway.
Ciao, Michael.
On Thu, Jul 26, 2018 at 01:34:52PM +0200, Hallvard Breien Furuseth wrote:
I were implementing a new LDAP server, I'd pick a higher default. But I'd rather not weaken security defaults in existing software.
In IRC, hbf went into a little more detail on what was meant by this: If you have an existing deployment with required SSF 100, then ldapi connections are not permitted and the admin may be expecting that. Upgrading slapd would then start allowing those ldapi connections, if there is no explicit olcLocalSSF: 71 setting, and the admin might not be expecting it, if they didn't read the upgrade notes carefully.
In general, changing defaults in a major release (i.e. 2.5) with documentation call-outs should be possible, but hbf's point is that for a security setting we should be conservative, and I agree with that and withdraw my proposal.
-
Dieter Klünter -
Hallvard Breien Furuseth -
Michael Ströder -
Ryan Tandy