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 <wbr...@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 <tvaug...@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 <prog...@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 <tvaug...@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 <wbr...@suse.de> wrote:
> > Hi there,
> >
> > > On 22 Apr 2021, at 03:52, Trevor Vaughan <tvaug...@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@lists.fedoraproject.org
> > > To unsubscribe send an email to
> 389-users-le...@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.fedoraproject.org
> > > 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@lists.fedoraproject.org
> > To unsubscribe send an email to 389-users-le...@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.fedoraproject.org
> > 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@lists.fedoraproject.org
> > To unsubscribe send an email to 389-users-le...@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.fedoraproject.org
> > 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@lists.fedoraproject.org
> > To unsubscribe send an email to 389-users-le...@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.fedoraproject.org
> > 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@lists.fedoraproject.org
> > To unsubscribe send an email to 389-users-le...@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.fedoraproject.org
> > 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@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@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.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@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.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to