Interestingly, if I remove the cipher specification, I get the result of ECDHE-RSA-AES128-GCM-SHA256.
Can you see if this also happens with your version of nss? Thanks, Trevor On Wed, Apr 28, 2021 at 8:27 AM Trevor Vaughan <[email protected]> wrote: > So, I just ran this test with selfserv as you have above and everything > worked as expected with s_client. > > It seems to be something in 389 itself. > > On Tue, Apr 27, 2021 at 6:32 PM Rob Crittenden <[email protected]> > wrote: > >> Trevor Vaughan wrote: >> > Going full circle on this, I confirmed using s_client that what I was >> > seeing was indeed happening but not for the reason that I thought it >> was. >> > >> > Given that the min_ssf is 256, the connection requires a 256-bit cipher >> > and hash to communicate with the server. >> > >> > Strangely, the internal strength logic on the 389-DS side appears to >> > pick ECDHE-RSA-AES128-GCM-SHA256 *before* ECDHE-RSA-AES256-GCM-SHA384. >> > Likewise, if I add any of the AES128 ciphers to the list after the >> > AES256 ciphers, one of the 128-bit ciphers will be chosen first. This >> > seems incorrect given that the server should be using the strongest >> > cipher suite available if possible. >> > >> > The client cipher order preference is completely ignored (which is >> fine). >> > >> > As pointed out in the last response, I did indeed need to explicitly >> > enable only the 256-bit+ hash/cipher combinations in the >> > confusingly-named nsSSL3Ciphers attribute. >> > >> > After figuring this out and dumping the internal supported cipher list, >> > I can confirm that the ciphers in the nsSSL3Ciphers list are the only >> > ones that are presented to the client. >> > >> > While not ideal, this does provide a solution to the issue where I don't >> > have to tell all system users that they need to nail up the cipher lists >> > on the client side in order for things to function properly. >> > >> > But that leaves me with two questions: >> > >> > 1) Why, when the nsslapd-minssf option is set in the global >> > configuration, does 389-DS not automatically prune any options that will >> > result in an unsuccessful connection. >> > >> > 2) Why is the internal cipher sorting order choosing weaker cipher >> > suites before stronger ones? >> >> I'm pretty sure that 389-ds still uses NSS for server-side crypto and >> unless something has changed NSS doesn't do cipher sorting. It picks the >> "best" for you. AFAIR the server has no say in the matter. >> >> But, as a goof I used a pure NSS server tool to see what happens and it >> picked the expected cipher. >> >> Enable your two ciphers (in hex form): >> >> $ /usr/lib64/nss/unsupported-tools/selfserv -n Server-Cert -d >> /etc/dirsrv/slapd-EXAMPLE-TEST/ -p 8389 -f >> /etc/dirsrv/slapd-EXAMPLE-TEST/pwdfile.txt -c :C02F -c :C030 -v -V >> tls1.2:tls1.2 >> >> run s_client: >> >> New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 >> Server public key is 2048 bit >> Secure Renegotiation IS supported >> Compression: NONE >> Expansion: NONE >> No ALPN negotiated >> SSL-Session: >> Protocol : TLSv1.2 >> Cipher : ECDHE-RSA-AES256-GCM-SHA384 >> Session-ID: >> 2AF9EFDDB3EA99C101C4E4F99A47CD479D294C15309D7E994ADA21C083D8E096 >> Session-ID-ctx: >> Master-Key: >> >> 85646A59B24D5A88080227BD59E328C688910FB0B2E2BAD77D7B1A96F6A9A3ACBF74EEC6C844A7D59527152928580743 >> PSK identity: None >> PSK identity hint: None >> SRP username: None >> Start Time: 1619562457 >> Timeout : 7200 (sec) >> Verify return code: 0 (ok) >> Extended master secret: yes >> >> So even more confusing unless I've goofed something up, sorry. I didn't >> mess with minssf, maybe that does make a difference. >> >> The ciphers are: >> >> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 0xC02F >> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 0xC030 >> >> Don't mean to stir up the mud but this may be a question for the NSS team. >> >> rob >> >> > On Mon, Apr 26, 2021 at 11:50 PM William Brown <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > Then youll need to disable everything except aes256 then I suspect >> > ... :( >> > >> > > On 25 Apr 2021, at 11:39, Trevor Vaughan <[email protected] >> > <mailto:[email protected]>> 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 <[email protected] >> > <mailto:[email protected]>> wrote: >> > > >> > > >> > > > On 24 Apr 2021, at 22:30, Trevor Vaughan < >> [email protected] >> > <mailto:[email protected]>> 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 <[email protected] >> > <mailto:[email protected]>> 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 >> > <[email protected] <mailto:[email protected]>> 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 <[email protected] >> > <mailto:[email protected]>> 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 >> > <[email protected] <mailto:[email protected]>> 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 >> > <[email protected] <mailto:[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] <mailto:[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] >> > <mailto:[email protected]>> wrote: >> > > > > Hi there, >> > > > > >> > > > > > On 22 Apr 2021, at 03:52, Trevor Vaughan >> > <[email protected] <mailto:[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] >> > <mailto:[email protected]> >> > > > > > To unsubscribe send an email to >> > [email protected] >> > <mailto:[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] >> > <mailto:[email protected]> >> > > > > To unsubscribe send an email to >> > [email protected] >> > <mailto:[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] >> > <mailto:[email protected]> >> > > > > To unsubscribe send an email to >> > [email protected] >> > <mailto:[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] >> > <mailto:[email protected]> >> > > > > To unsubscribe send an email to >> > [email protected] >> > <mailto:[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] >> > <mailto:[email protected]> >> > > > > To unsubscribe send an email to >> > [email protected] >> > <mailto:[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] >> > <mailto:[email protected]> >> > > > To unsubscribe send an email to >> > [email protected] >> > <mailto:[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-users mailing list -- [email protected] >> > <mailto:[email protected]> >> > > > To unsubscribe send an email to >> > [email protected] >> > <mailto:[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-users mailing list -- [email protected] >> > <mailto:[email protected]> >> > > > To unsubscribe send an email to >> > [email protected] >> > <mailto:[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-users mailing list -- [email protected] >> > <mailto:[email protected]> >> > > > To unsubscribe send an email to >> > [email protected] >> > <mailto:[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] >> > <mailto:[email protected]> >> > > To unsubscribe send an email to >> > [email protected] >> > <mailto:[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-users mailing list -- [email protected] >> > <mailto:[email protected]> >> > > To unsubscribe send an email to >> > [email protected] >> > <mailto:[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] >> > <mailto:[email protected]> >> > To unsubscribe send an email to >> > [email protected] >> > <mailto:[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 >> > >> >> > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 x788 > > -- This account not approved for unencrypted proprietary information -- > -- 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
