Hi William, In terms of the STARTTLS bits (in theory) properly configuring your client software mitigates the password leak risk. But this also happens with pure (non-RFC) LDAPS connections.
The docs note that minssf applies to the crypto required bits as well as the SASL layer. Ignoring most of that, my issue is that I don't understand why I have to nail my client software to ciphers explicitly known by 389-DS instead of the two negotiating the strongest things possible out of the gate. For instance, if I use AES256 with a minssf=256, everything works just fine. But, if I use AES128:AES256:@STRENGTH (which should sort strongest to weakest) then access is denied. How do I get 389-DS to negotiate the strongest ciphers first (regardless of the method)? Thanks, Trevor On Wed, Apr 21, 2021 at 7:34 PM William Brown <[email protected]> wrote: > Hi there, > > > On 22 Apr 2021, at 03:52, Trevor Vaughan <[email protected]> wrote: > > > > Hi All, > > > > OS Version: CentOS 8 > > 389-DS Version: 1.4.3.22 from EPEL > > > > I have a server set up with minssf=256 and have been surprised that > either 389-DS, or openssl, does not appear to be doing what I would > consider a logical TLS negotiation. > > > > I had thought that the system would start with the strongest cipher and > then negotiate down to something that was acceptable. > > > > Instead, I'm finding that I have to nail up the ciphers to something > that the 389-DS server both recognizes and is within the expected SSF. > > > > Is this expected behavior or do I have something configured incorrectly? > > That's not what minssf does. > > minssf says "during a bind operation, reject if the encryption strength > used is less than 256 bits or equivalent". > > The "bit strength" is arbitrary though, because it's a concept from sasl, > and generally is very broken. > > Remember, minssf does NOT do what you think though! Because bind is the > *first* message on the wire, the series of operations is > > > client server > open plain text conn -> > <- accept connection > send bind on conn -> > <- reject due to minsff too weak. > > > So you have already leaked the password! > > > The only way to ensure this does not occur is to set "nsslapd-port: 0" > which disables plaintext. Then you *only* use ldaps on port 636, which is > guarantee encrypted from the start. > > It is worth noting that the use of starttls over ldap, does *NOT* mitigate > this issue, for a similar reason. > > > Caveat: If you are using kerberos/gssapi you can NOT disable plaintext > ldap due to these protocols attempting to install their own encryption > layers. > > > Hope that helps, > > > > > > Thanks, > > > > Trevor > > > > -- > > Trevor Vaughan > > Vice President, Onyx Point, Inc > > (410) 541-6699 x788 > > > > -- This account not approved for unencrypted proprietary information -- > > _______________________________________________ > > 389-users mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/[email protected] > > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server > SUSE Labs, Australia > _______________________________________________ > 389-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/[email protected] > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --
_______________________________________________ 389-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
