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?
Thanks,
Trevor
On Mon, Apr 26, 2021 at 11:50 PM William Brown <wbrown(a)suse.de> wrote:
Then youll need to disable everything except aes256 then I suspect
... :(
> On 25 Apr 2021, at 11:39, Trevor Vaughan <tvaughan(a)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 <wbrown(a)suse.de> wrote:
>
>
> > On 24 Apr 2021, at 22:30, Trevor Vaughan <tvaughan(a)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 <msauton(a)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...
> >
> > and NSS source:
> > ./lib/ssl/ssl3con.c
> > ./lib/ssl/sslenum.c
> >
> >
> > On Fri, Apr 23, 2021 at 4:57 PM Trevor Vaughan <tvaughan(a)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 <wbrown(a)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 <tvaughan(a)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 <progier(a)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 <
tvaughan(a)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 <wbrown(a)suse.de>
wrote:
> > > Hi there,
> > >
> > > > On 22 Apr 2021, at 03:52, Trevor Vaughan
<tvaughan(a)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(a)lists.fedoraproject.org
> > > > To unsubscribe send an email to
389-users-leave(a)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.fedoraproje...
> > > > 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(a)lists.fedoraproject.org
> > > To unsubscribe send an email to
389-users-leave(a)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.fedoraproje...
> > > 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(a)lists.fedoraproject.org
> > > To unsubscribe send an email to
389-users-leave(a)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.fedoraproje...
> > > 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(a)lists.fedoraproject.org
> > > To unsubscribe send an email to
389-users-leave(a)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.fedoraproje...
> > > 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(a)lists.fedoraproject.org
> > > To unsubscribe send an email to
389-users-leave(a)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.fedoraproje...
> > > 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(a)lists.fedoraproject.org
> > To unsubscribe send an email to
389-users-leave(a)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.fedoraproje...
> > Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
> > _______________________________________________
> > 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> > To unsubscribe send an email to
389-users-leave(a)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.fedoraproje...
> > Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
> > _______________________________________________
> > 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> > To unsubscribe send an email to
389-users-leave(a)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.fedoraproje...
> > Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
> > _______________________________________________
> > 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> > To unsubscribe send an email to
389-users-leave(a)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.fedoraproje...
> > 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(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
> Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
> _______________________________________________
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
> 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(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
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 --