Well, in this case, I've got to be able to work with regulatory requirements so not much I can do there.
Trevor
On Sat, Apr 24, 2021, 9:03 PM William Brown <wbrown@suse.de> wrote:
> On 24 Apr 2021, at 22:30, Trevor Vaughan <tvaughan@onyxpoint.com> wrote:
>
> Hi Marc,
>
> I was under the impression that it would pick the highest supported, but that doesn't seem to be what is happening based on my previous example.
>
> Instead, it seems to just be picking the first compatible, regardless of strength.
It choose aes128 over 256 because of processing speed, and "strong enough".
>
> Trevor
>
> On Fri, Apr 23, 2021, 10:03 PM Marc Sauton <msauton@redhat.com> wrote:
> about ciphers order and TLS cipher suite discovery, NSS will pick the one with highest strength from the available ciphers, and compatible with the TLS client ( handshake)
>
> you can check the configuration with for example (replace the string m1 with an instance name):
> dsconf m1 security get
> dsconf m1 security ciphers list
> dsconf m1 security ciphers list --supported | less
> dsconf m1 security ciphers list --enabled
> ldapsearch -o ldif-wrap=no -LLLxD "cn=Directory Manager" -W -b cn=encryption,cn=config | less
>
> and to set ciphers (can be "delicate"):
> /usr/lib64/nss/unsupported-tools/listsuites | grep -B1 --no-group-separator "Enabled" | less
> dsconf m1 security ciphers set xxxxx
>
> doc ref:
> https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/enabling_tls#setting_encryption_ciphers
>
> and NSS source:
> ./lib/ssl/ssl3con.c
> ./lib/ssl/sslenum.c
>
>
> On Fri, Apr 23, 2021 at 4:57 PM Trevor Vaughan <tvaughan@onyxpoint.com> wrote:
> 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@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 <tvaughan@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 <progier@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@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@suse.de> wrote:
> > Hi there,
> >
> > > On 22 Apr 2021, at 03:52, Trevor Vaughan <tvaughan@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-leave@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-leave@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-leave@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-leave@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-leave@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-leave@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-leave@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-leave@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-leave@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-leave@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
No comments:
Post a Comment