Bill and Pierre, Thanks for the responses!
It sounds like I have to figure out how to configure the NSS library for 389-DS specifically. In EL8+ I know that I can configure the global crypto policy but I'm hoping that I can do it for the specific application. I haven't found anything in the documentation so far but at least this gets me pointed in the right direction. Thanks, Trevor On Fri, Apr 23, 2021 at 4:42 AM Pierre Rogier <[email protected]> wrote: > Hi Trevor, > > I do not think it is possible to specify the cypher order negotiation: > I am not sure whether TLS protocol allow to specify an order when > negotiating the cypher, > but at 389 level there is no way to specify an order: > The NSS security layer provides the list of supported cypher and 389 use > nsSSL3Ciphers > config parameter to enable/disable theses cyphers in the list (without > changing the order) So my feeling is that if there is an order it is > up to the different > security layer implementations and may differs between the > applications, > > Regards, > Pierre > > On Thu, Apr 22, 2021 at 7:28 PM Trevor Vaughan <[email protected]> > wrote: > >> 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 >> > > > -- > -- > > 389 Directory Server Development Team > _______________________________________________ > 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
