William Brown wrote:
On Fri, 2017-11-17 at 08:34 +0100, Michael Ströder wrote:
William Brown wrote:
Just want to point out there are some security risks with ssf settings. I have documented these here:
https://fy.blackhats.net.au/blog/html/2016/11/23/the_minssf_trap.ht ml
Nice writeup. I always considered SSF values to be naive and somewhat overrated. People expect too much when looking at these numbers - especially regarding the "strength" of cryptographic algorithms which changes over time anyway with new cryptanalysis results coming up.
Personally I always try to implement a TLS-is-must policy and prefer LDAPS (with correct protocol and ciphersuites configured) over LDAP/StartTLS to avoid this kind of pre-TLS leakage. Yes, I deliberately ignore "LDAPS is deprecated". ;-]
I agree. If only there was a standards working group that could deprecate startTLS in favour of TLS .... :)
I have to agree as well. On my own servers I also use TLS on other "plaintext" ports too (such as pop3 and others) that no one has any business connecting to in plaintext.
Furthermore some LDAP server implementation (IIRC e.g. MS AD) refuse to accept SASL/GSSAPI bind requests sent over TLS-secured channel. Which is IMO also somewhat questionable.
Yes, I really agree. While a plain text port exists, data leaks are possible. We should really improve this situation, where we have TLS for all data to prevent these mistakes.
I think a big part of the issue is that GSSAPI forces the encryption layer, and can't work via an already encrypted channel. The people I know involved in this space are really resistant to changing this due to the "kerberos centric" nature of the products.
Interesting. Our libldap/liblber works fine with GSSAPI's encryption layered over TLS and vice versa.
On Mon, 2017-11-20 at 11:22 +0000, Howard Chu wrote:
William Brown wrote:
On Fri, 2017-11-17 at 08:34 +0100, Michael Ströder wrote:
William Brown wrote:
Just want to point out there are some security risks with ssf settings. I have documented these here:
https://fy.blackhats.net.au/blog/html/2016/11/23/the_minssf_tra p.ht ml
Nice writeup. I always considered SSF values to be naive and somewhat overrated. People expect too much when looking at these numbers - especially regarding the "strength" of cryptographic algorithms which changes over time anyway with new cryptanalysis results coming up.
Personally I always try to implement a TLS-is-must policy and prefer LDAPS (with correct protocol and ciphersuites configured) over LDAP/StartTLS to avoid this kind of pre-TLS leakage. Yes, I deliberately ignore "LDAPS is deprecated". ;-]
I agree. If only there was a standards working group that could deprecate startTLS in favour of TLS .... :)
I have to agree as well. On my own servers I also use TLS on other "plaintext" ports too (such as pop3 and others) that no one has any business connecting to in plaintext.
Yep. TLS and end-to-end is the way of the future. We need to update our documents to support this :)
Furthermore some LDAP server implementation (IIRC e.g. MS AD) refuse to accept SASL/GSSAPI bind requests sent over TLS-secured channel. Which is IMO also somewhat questionable.
Yes, I really agree. While a plain text port exists, data leaks are possible. We should really improve this situation, where we have TLS for all data to prevent these mistakes.
I think a big part of the issue is that GSSAPI forces the encryption layer, and can't work via an already encrypted channel. The people I know involved in this space are really resistant to changing this due to the "kerberos centric" nature of the products.
Interesting. Our libldap/liblber works fine with GSSAPI's encryption layered over TLS and vice versa.
Sadly your libldap/liblber is not the only one we have to use. I'm told that especially AD for IPA trust's is unable to do GSSAPI-over-TLS.
Really, IMO if the SSF is already > 1, then GSSAPI shouldn't install encryption layer, but you know, I'm not the one who writes the SASL code ... If you have some contacts in this space, I'm open to suggestion as to how we can proceed to improve this,
openldap-technical@openldap.org
-
Howard Chu -
William Brown