Hi William,
IMHO the password leak with wrongly configured application is not a really interesting argument as there is absolutely no way to prevent that, EVEN BY DISABLING NON SECURE PORT.
IMHO the password leak with wrongly configured application is not a really interesting argument as there is absolutely no way to prevent that, EVEN BY DISABLING NON SECURE PORT.
If you configure an application over LDAP (instead of LDAPS) targetted on secure port
the application will send the clear bind request without attempting the SSL/TLS handshake
the server NSS layer will reject the PDU but once again it is too late and the password leaked. (the only difference is when the operation get aborted on server side: (inside NSS layer or in server bind handling)
the server NSS layer will reject the PDU but once again it is too late and the password leaked. (the only difference is when the operation get aborted on server side: (inside NSS layer or in server bind handling)
The only solution is to have applications that insure that password are not sent on insecure connection ...
Regards
Pierre
Regards
Pierre
On Fri, Apr 23, 2021 at 1:41 AM William Brown <wbrown@xxxxxxx> wrote:
> On 23 Apr 2021, at 03:23, Trevor Vaughan <tvaughan@xxxxxxxxxxxxx> 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.
No it doesn't.
In starttls you start on a plaintext port, and you need to send either:
* starttls
* bind
There is a possibility you send the bind before the starttls op, so you leak the password.
With LDAPS you *must* have TLS correctly setup before you can even start a single ldap message, meaning that the bind is never able to be leaked.
LDAPS is the *only* secure method to communicate to an LDAP server today.
>
> 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.
Yes because aes128 is an ssf of 128. Second, NSS doesn't sort these at all, because it doesn't know how to sort them, so it takes them in the order you provide. It's probably better to use the system policy and the future setting (see below).
But remember also. minssf is only applied *after* the bind message is already sent AKA the damage is already done because you may have leaked it unless you use LDAPS only.
>
> How do I get 389-DS to negotiate the strongest ciphers first (regardless of the method)?
Set your system cipher policy to "future". This has the proper orders for ciphers.
https://fedoraproject.org/wiki/Changes/CryptoPolicy
>
> Thanks,
>
> Trevor
>
> On Wed, Apr 21, 2021 at 7:34 PM William Brown <wbrown@xxxxxxx> wrote:
> Hi there,
>
> > On 22 Apr 2021, at 03:52, Trevor Vaughan <tvaughan@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
> > To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
> > 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@xxxxxxxxxxxxxxxxxxxxxxx
> > 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@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
--
389 Directory Server Development Team
389 Directory Server Development Team
_______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
