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,
--
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane
Howard Chu
William Brown