about ciphers order and TLS cipher suite discovery, NSS will pick the one with highest strength from the available ciphers, and compatible with the TLS client ( handshake)
you can check the configuration with for example (replace the string m1 with an instance name): dsconf m1 security get dsconf m1 security ciphers list dsconf m1 security ciphers list --supported | less dsconf m1 security ciphers list --enabled ldapsearch -o ldif-wrap=no -LLLxD "cn=Directory Manager" -W -b cn=encryption,cn=config | less and to set ciphers (can be "delicate"): /usr/lib64/nss/unsupported-tools/listsuites | grep -B1 --no-group-separator "Enabled" | less dsconf m1 security ciphers set xxxxx doc ref: https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/enabling_tls#setting_encryption_ciphers and NSS source: ./lib/ssl/ssl3con.c ./lib/ssl/sslenum.c On Fri, Apr 23, 2021 at 4:57 PM Trevor Vaughan <tvaug...@onyxpoint.com> wrote: > William, > > I do apologize! I'll keep that in mind in the future. > > Thanks again for your help, > > Trevor > > On Fri, Apr 23, 2021, 7:50 PM William Brown <wbr...@suse.de> wrote: > >> Sorry to call this out, but my name is "William" not "Bill". I have >> personal reasons to dislike being called that name. >> >> Regardless, happy to help out :) >> >> > On 23 Apr 2021, at 22:11, Trevor Vaughan <tvaug...@onyxpoint.com> >> wrote: >> > >> > 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 <prog...@redhat.com> >> 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 <tvaug...@onyxpoint.com> >> 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 <wbr...@suse.de> wrote: >> > Hi there, >> > >> > > On 22 Apr 2021, at 03:52, Trevor Vaughan <tvaug...@onyxpoint.com> >> 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 -- 389-users@lists.fedoraproject.org >> > > To unsubscribe send an email to >> 389-users-le...@lists.fedoraproject.org >> > > 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/389-users@lists.fedoraproject.org >> > > 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 -- 389-users@lists.fedoraproject.org >> > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org >> > 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/389-users@lists.fedoraproject.org >> > 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 -- 389-users@lists.fedoraproject.org >> > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org >> > 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/389-users@lists.fedoraproject.org >> > Do not reply to spam on the list, report it: >> https://pagure.io/fedora-infrastructure >> > >> > >> > -- >> > -- >> > >> > 389 Directory Server Development Team >> > _______________________________________________ >> > 389-users mailing list -- 389-users@lists.fedoraproject.org >> > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org >> > 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/389-users@lists.fedoraproject.org >> > 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 -- 389-users@lists.fedoraproject.org >> > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org >> > 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/389-users@lists.fedoraproject.org >> > 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 -- 389-users@lists.fedoraproject.org >> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org >> 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/389-users@lists.fedoraproject.org >> Do not reply to spam on the list, report it: >> https://pagure.io/fedora-infrastructure >> > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > 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/389-users@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure >
_______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org 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/389-users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
