[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ssf Security Question
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