Then youll need to disable everything except aes256 then I suspect ... :( > On 25 Apr 2021, at 11:39, Trevor Vaughan <tvaug...@onyxpoint.com> wrote: > > Well, in this case, I've got to be able to work with regulatory requirements > so not much I can do there. > > Trevor > > On Sat, Apr 24, 2021, 9:03 PM William Brown <wbr...@suse.de> wrote: > > > > On 24 Apr 2021, at 22:30, Trevor Vaughan <tvaug...@onyxpoint.com> wrote: > > > > Hi Marc, > > > > I was under the impression that it would pick the highest supported, but > > that doesn't seem to be what is happening based on my previous example. > > > > Instead, it seems to just be picking the first compatible, regardless of > > strength. > > It choose aes128 over 256 because of processing speed, and "strong enough". > > > > > Trevor > > > > On Fri, Apr 23, 2021, 10:03 PM Marc Sauton <msau...@redhat.com> wrote: > > 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 > > _______________________________________________ > > 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
— 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
