Re: minssf and TLS cipher ordering

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxxx> 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@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.
>
> 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@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
>
>
> --
> --
>
> 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
>
>
> --
> 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-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

[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux