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