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 --