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?
Thanks,
Trevor
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.... 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
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....
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.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 23 Apr 2021, at 03:23, 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.
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@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.... 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.... 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.... 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
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. 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 only solution is to have applications that insure that password are not sent on insecure connection ...
Regards Pierre
On Fri, Apr 23, 2021 at 1:41 AM William Brown wbrown@suse.de wrote:
On 23 Apr 2021, at 03:23, 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.
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@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....
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....
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....
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.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
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....
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.... 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.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
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....
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.... 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.... 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.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
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.... 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.... 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.... 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.... 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.... 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
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....
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....
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....
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....
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....
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.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
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/ht...
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....
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....
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....
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....
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....
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.... 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.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
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.
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/ht...
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....
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....
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....
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....
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....
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.... 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.... 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.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
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/ht...
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.... 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.... 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.... 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.... 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.... 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.... 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.... 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.... 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.... 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
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/ht...
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....
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....
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....
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....
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....
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....
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....
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....
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....
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.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Then youll need to disable everything except aes256 then I suspect ... :(
On 25 Apr 2021, at 11:39, Trevor Vaughan tvaughan@onyxpoint.com wrote:
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/ht...
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.... 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.... 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.... 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.... 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.... 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.... 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.... 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.... 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.... 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.... 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.... 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
Going full circle on this, I confirmed using s_client that what I was seeing was indeed happening but not for the reason that I thought it was.
Given that the min_ssf is 256, the connection requires a 256-bit cipher and hash to communicate with the server.
Strangely, the internal strength logic on the 389-DS side appears to pick ECDHE-RSA-AES128-GCM-SHA256 *before* ECDHE-RSA-AES256-GCM-SHA384. Likewise, if I add any of the AES128 ciphers to the list after the AES256 ciphers, one of the 128-bit ciphers will be chosen first. This seems incorrect given that the server should be using the strongest cipher suite available if possible.
The client cipher order preference is completely ignored (which is fine).
As pointed out in the last response, I did indeed need to explicitly enable only the 256-bit+ hash/cipher combinations in the confusingly-named nsSSL3Ciphers attribute.
After figuring this out and dumping the internal supported cipher list, I can confirm that the ciphers in the nsSSL3Ciphers list are the only ones that are presented to the client.
While not ideal, this does provide a solution to the issue where I don't have to tell all system users that they need to nail up the cipher lists on the client side in order for things to function properly.
But that leaves me with two questions:
1) Why, when the nsslapd-minssf option is set in the global configuration, does 389-DS not automatically prune any options that will result in an unsuccessful connection.
2) Why is the internal cipher sorting order choosing weaker cipher suites before stronger ones?
Thanks,
Trevor
On Mon, Apr 26, 2021 at 11:50 PM William Brown wbrown@suse.de wrote:
Then youll need to disable everything except aes256 then I suspect ... :(
On 25 Apr 2021, at 11:39, Trevor Vaughan tvaughan@onyxpoint.com wrote:
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/ht...
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....
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....
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....
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....
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....
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....
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....
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....
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....
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....
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....
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.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Trevor Vaughan wrote:
Going full circle on this, I confirmed using s_client that what I was seeing was indeed happening but not for the reason that I thought it was.
Given that the min_ssf is 256, the connection requires a 256-bit cipher and hash to communicate with the server.
Strangely, the internal strength logic on the 389-DS side appears to pick ECDHE-RSA-AES128-GCM-SHA256 *before* ECDHE-RSA-AES256-GCM-SHA384. Likewise, if I add any of the AES128 ciphers to the list after the AES256 ciphers, one of the 128-bit ciphers will be chosen first. This seems incorrect given that the server should be using the strongest cipher suite available if possible.
The client cipher order preference is completely ignored (which is fine).
As pointed out in the last response, I did indeed need to explicitly enable only the 256-bit+ hash/cipher combinations in the confusingly-named nsSSL3Ciphers attribute.
After figuring this out and dumping the internal supported cipher list, I can confirm that the ciphers in the nsSSL3Ciphers list are the only ones that are presented to the client.
While not ideal, this does provide a solution to the issue where I don't have to tell all system users that they need to nail up the cipher lists on the client side in order for things to function properly.
But that leaves me with two questions:
- Why, when the nsslapd-minssf option is set in the global
configuration, does 389-DS not automatically prune any options that will result in an unsuccessful connection.
- Why is the internal cipher sorting order choosing weaker cipher
suites before stronger ones?
I'm pretty sure that 389-ds still uses NSS for server-side crypto and unless something has changed NSS doesn't do cipher sorting. It picks the "best" for you. AFAIR the server has no say in the matter.
But, as a goof I used a pure NSS server tool to see what happens and it picked the expected cipher.
Enable your two ciphers (in hex form):
$ /usr/lib64/nss/unsupported-tools/selfserv -n Server-Cert -d /etc/dirsrv/slapd-EXAMPLE-TEST/ -p 8389 -f /etc/dirsrv/slapd-EXAMPLE-TEST/pwdfile.txt -c :C02F -c :C030 -v -V tls1.2:tls1.2
run s_client:
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 2AF9EFDDB3EA99C101C4E4F99A47CD479D294C15309D7E994ADA21C083D8E096 Session-ID-ctx: Master-Key: 85646A59B24D5A88080227BD59E328C688910FB0B2E2BAD77D7B1A96F6A9A3ACBF74EEC6C844A7D59527152928580743 PSK identity: None PSK identity hint: None SRP username: None Start Time: 1619562457 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: yes
So even more confusing unless I've goofed something up, sorry. I didn't mess with minssf, maybe that does make a difference.
The ciphers are:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 0xC02F TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 0xC030
Don't mean to stir up the mud but this may be a question for the NSS team.
rob
On Mon, Apr 26, 2021 at 11:50 PM William Brown <wbrown@suse.de mailto:wbrown@suse.de> wrote:
Then youll need to disable everything except aes256 then I suspect ... :( > On 25 Apr 2021, at 11:39, Trevor Vaughan <tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com>> wrote: > > 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 <mailto:wbrown@suse.de>> wrote: > > > > On 24 Apr 2021, at 22:30, Trevor Vaughan <tvaughan@onyxpoint.com <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:wbrown@suse.de>> wrote: > > > Hi there, > > > > > > > On 22 Apr 2021, at 03:52, Trevor Vaughan <tvaughan@onyxpoint.com <mailto: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 <mailto:389-users@lists.fedoraproject.org> > > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
How odd, maybe it's the version in EPEL.
On Tue, Apr 27, 2021 at 6:32 PM Rob Crittenden rcritten@redhat.com wrote:
Trevor Vaughan wrote:
Going full circle on this, I confirmed using s_client that what I was seeing was indeed happening but not for the reason that I thought it was.
Given that the min_ssf is 256, the connection requires a 256-bit cipher and hash to communicate with the server.
Strangely, the internal strength logic on the 389-DS side appears to pick ECDHE-RSA-AES128-GCM-SHA256 *before* ECDHE-RSA-AES256-GCM-SHA384. Likewise, if I add any of the AES128 ciphers to the list after the AES256 ciphers, one of the 128-bit ciphers will be chosen first. This seems incorrect given that the server should be using the strongest cipher suite available if possible.
The client cipher order preference is completely ignored (which is fine).
As pointed out in the last response, I did indeed need to explicitly enable only the 256-bit+ hash/cipher combinations in the confusingly-named nsSSL3Ciphers attribute.
After figuring this out and dumping the internal supported cipher list, I can confirm that the ciphers in the nsSSL3Ciphers list are the only ones that are presented to the client.
While not ideal, this does provide a solution to the issue where I don't have to tell all system users that they need to nail up the cipher lists on the client side in order for things to function properly.
But that leaves me with two questions:
- Why, when the nsslapd-minssf option is set in the global
configuration, does 389-DS not automatically prune any options that will result in an unsuccessful connection.
- Why is the internal cipher sorting order choosing weaker cipher
suites before stronger ones?
I'm pretty sure that 389-ds still uses NSS for server-side crypto and unless something has changed NSS doesn't do cipher sorting. It picks the "best" for you. AFAIR the server has no say in the matter.
But, as a goof I used a pure NSS server tool to see what happens and it picked the expected cipher.
Enable your two ciphers (in hex form):
$ /usr/lib64/nss/unsupported-tools/selfserv -n Server-Cert -d /etc/dirsrv/slapd-EXAMPLE-TEST/ -p 8389 -f /etc/dirsrv/slapd-EXAMPLE-TEST/pwdfile.txt -c :C02F -c :C030 -v -V tls1.2:tls1.2
run s_client:
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 2AF9EFDDB3EA99C101C4E4F99A47CD479D294C15309D7E994ADA21C083D8E096 Session-ID-ctx: Master-Key:
85646A59B24D5A88080227BD59E328C688910FB0B2E2BAD77D7B1A96F6A9A3ACBF74EEC6C844A7D59527152928580743 PSK identity: None PSK identity hint: None SRP username: None Start Time: 1619562457 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: yes
So even more confusing unless I've goofed something up, sorry. I didn't mess with minssf, maybe that does make a difference.
The ciphers are:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 0xC02F TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 0xC030
Don't mean to stir up the mud but this may be a question for the NSS team.
rob
On Mon, Apr 26, 2021 at 11:50 PM William Brown <wbrown@suse.de mailto:wbrown@suse.de> wrote:
Then youll need to disable everything except aes256 then I suspect ... :( > On 25 Apr 2021, at 11:39, Trevor Vaughan <tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com>> wrote: > > 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 <mailto:wbrown@suse.de>> wrote: > > > > On 24 Apr 2021, at 22:30, Trevor Vaughan <tvaughan@onyxpoint.com <mailto: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 <mailto: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/ht...
> > > > 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:wbrown@suse.de>> wrote: > > > Hi there, > > > > > > > On 22 Apr 2021, at 03:52, Trevor Vaughan <tvaughan@onyxpoint.com <mailto: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 <mailto:389-users@lists.fedoraproject.org> > > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > > > 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 <mailto:389-users@lists.fedoraproject.org> > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > > 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 <mailto:389-users@lists.fedoraproject.org> > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > > 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 <mailto:389-users@lists.fedoraproject.org> > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > > 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 <mailto:389-users@lists.fedoraproject.org> > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > > 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 <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > > _______________________________________________ > > 389-users mailing list -- 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > > _______________________________________________ > > 389-users mailing list -- 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > > _______________________________________________ > > 389-users mailing list -- 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > 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 <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> 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 <mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
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....
Do not reply to spam on the list, report it:
Trevor Vaughan wrote:
How odd, maybe it's the version in EPEL.
I tested on a Fedora 32 VM I had lying around with an IPA installation.
nss-3.62.0-1.fc32.x86_64
And this excluded 389-ds other than using its NSS database.
rob
On Tue, Apr 27, 2021 at 6:32 PM Rob Crittenden <rcritten@redhat.com mailto:rcritten@redhat.com> wrote:
Trevor Vaughan wrote: > Going full circle on this, I confirmed using s_client that what I was > seeing was indeed happening but not for the reason that I thought it was. > > Given that the min_ssf is 256, the connection requires a 256-bit cipher > and hash to communicate with the server. > > Strangely, the internal strength logic on the 389-DS side appears to > pick ECDHE-RSA-AES128-GCM-SHA256 *before* ECDHE-RSA-AES256-GCM-SHA384. > Likewise, if I add any of the AES128 ciphers to the list after the > AES256 ciphers, one of the 128-bit ciphers will be chosen first. This > seems incorrect given that the server should be using the strongest > cipher suite available if possible. > > The client cipher order preference is completely ignored (which is fine). > > As pointed out in the last response, I did indeed need to explicitly > enable only the 256-bit+ hash/cipher combinations in the > confusingly-named nsSSL3Ciphers attribute. > > After figuring this out and dumping the internal supported cipher list, > I can confirm that the ciphers in the nsSSL3Ciphers list are the only > ones that are presented to the client. > > While not ideal, this does provide a solution to the issue where I don't > have to tell all system users that they need to nail up the cipher lists > on the client side in order for things to function properly. > > But that leaves me with two questions: > > 1) Why, when the nsslapd-minssf option is set in the global > configuration, does 389-DS not automatically prune any options that will > result in an unsuccessful connection. > > 2) Why is the internal cipher sorting order choosing weaker cipher > suites before stronger ones? I'm pretty sure that 389-ds still uses NSS for server-side crypto and unless something has changed NSS doesn't do cipher sorting. It picks the "best" for you. AFAIR the server has no say in the matter. But, as a goof I used a pure NSS server tool to see what happens and it picked the expected cipher. Enable your two ciphers (in hex form): $ /usr/lib64/nss/unsupported-tools/selfserv -n Server-Cert -d /etc/dirsrv/slapd-EXAMPLE-TEST/ -p 8389 -f /etc/dirsrv/slapd-EXAMPLE-TEST/pwdfile.txt -c :C02F -c :C030 -v -V tls1.2:tls1.2 run s_client: New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 2AF9EFDDB3EA99C101C4E4F99A47CD479D294C15309D7E994ADA21C083D8E096 Session-ID-ctx: Master-Key: 85646A59B24D5A88080227BD59E328C688910FB0B2E2BAD77D7B1A96F6A9A3ACBF74EEC6C844A7D59527152928580743 PSK identity: None PSK identity hint: None SRP username: None Start Time: 1619562457 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: yes So even more confusing unless I've goofed something up, sorry. I didn't mess with minssf, maybe that does make a difference. The ciphers are: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 0xC02F TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 0xC030 Don't mean to stir up the mud but this may be a question for the NSS team. rob > On Mon, Apr 26, 2021 at 11:50 PM William Brown <wbrown@suse.de <mailto:wbrown@suse.de> > <mailto:wbrown@suse.de <mailto:wbrown@suse.de>>> wrote: > > Then youll need to disable everything except aes256 then I suspect > ... :( > > > On 25 Apr 2021, at 11:39, Trevor Vaughan <tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com> > <mailto:tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com>>> wrote: > > > > 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 <mailto:wbrown@suse.de> > <mailto:wbrown@suse.de <mailto:wbrown@suse.de>>> wrote: > > > > > > > On 24 Apr 2021, at 22:30, Trevor Vaughan <tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com> > <mailto:tvaughan@onyxpoint.com <mailto: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 <mailto:msauton@redhat.com> > <mailto:msauton@redhat.com <mailto: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 <mailto:tvaughan@onyxpoint.com> <mailto:tvaughan@onyxpoint.com <mailto: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 <mailto:wbrown@suse.de> > <mailto:wbrown@suse.de <mailto: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 <mailto:tvaughan@onyxpoint.com> <mailto:tvaughan@onyxpoint.com <mailto: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 <mailto:progier@redhat.com> <mailto:progier@redhat.com <mailto: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 <mailto:tvaughan@onyxpoint.com> <mailto:tvaughan@onyxpoint.com <mailto: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 <mailto:wbrown@suse.de> > <mailto:wbrown@suse.de <mailto:wbrown@suse.de>>> wrote: > > > > Hi there, > > > > > > > > > On 22 Apr 2021, at 03:52, Trevor Vaughan > <tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com> <mailto:tvaughan@onyxpoint.com <mailto: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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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 --
So, I just ran this test with selfserv as you have above and everything worked as expected with s_client.
It seems to be something in 389 itself.
On Tue, Apr 27, 2021 at 6:32 PM Rob Crittenden rcritten@redhat.com wrote:
Trevor Vaughan wrote:
Going full circle on this, I confirmed using s_client that what I was seeing was indeed happening but not for the reason that I thought it was.
Given that the min_ssf is 256, the connection requires a 256-bit cipher and hash to communicate with the server.
Strangely, the internal strength logic on the 389-DS side appears to pick ECDHE-RSA-AES128-GCM-SHA256 *before* ECDHE-RSA-AES256-GCM-SHA384. Likewise, if I add any of the AES128 ciphers to the list after the AES256 ciphers, one of the 128-bit ciphers will be chosen first. This seems incorrect given that the server should be using the strongest cipher suite available if possible.
The client cipher order preference is completely ignored (which is fine).
As pointed out in the last response, I did indeed need to explicitly enable only the 256-bit+ hash/cipher combinations in the confusingly-named nsSSL3Ciphers attribute.
After figuring this out and dumping the internal supported cipher list, I can confirm that the ciphers in the nsSSL3Ciphers list are the only ones that are presented to the client.
While not ideal, this does provide a solution to the issue where I don't have to tell all system users that they need to nail up the cipher lists on the client side in order for things to function properly.
But that leaves me with two questions:
- Why, when the nsslapd-minssf option is set in the global
configuration, does 389-DS not automatically prune any options that will result in an unsuccessful connection.
- Why is the internal cipher sorting order choosing weaker cipher
suites before stronger ones?
I'm pretty sure that 389-ds still uses NSS for server-side crypto and unless something has changed NSS doesn't do cipher sorting. It picks the "best" for you. AFAIR the server has no say in the matter.
But, as a goof I used a pure NSS server tool to see what happens and it picked the expected cipher.
Enable your two ciphers (in hex form):
$ /usr/lib64/nss/unsupported-tools/selfserv -n Server-Cert -d /etc/dirsrv/slapd-EXAMPLE-TEST/ -p 8389 -f /etc/dirsrv/slapd-EXAMPLE-TEST/pwdfile.txt -c :C02F -c :C030 -v -V tls1.2:tls1.2
run s_client:
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 2AF9EFDDB3EA99C101C4E4F99A47CD479D294C15309D7E994ADA21C083D8E096 Session-ID-ctx: Master-Key:
85646A59B24D5A88080227BD59E328C688910FB0B2E2BAD77D7B1A96F6A9A3ACBF74EEC6C844A7D59527152928580743 PSK identity: None PSK identity hint: None SRP username: None Start Time: 1619562457 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: yes
So even more confusing unless I've goofed something up, sorry. I didn't mess with minssf, maybe that does make a difference.
The ciphers are:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 0xC02F TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 0xC030
Don't mean to stir up the mud but this may be a question for the NSS team.
rob
On Mon, Apr 26, 2021 at 11:50 PM William Brown <wbrown@suse.de mailto:wbrown@suse.de> wrote:
Then youll need to disable everything except aes256 then I suspect ... :( > On 25 Apr 2021, at 11:39, Trevor Vaughan <tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com>> wrote: > > 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 <mailto:wbrown@suse.de>> wrote: > > > > On 24 Apr 2021, at 22:30, Trevor Vaughan <tvaughan@onyxpoint.com <mailto: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 <mailto: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/ht...
> > > > 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:wbrown@suse.de>> wrote: > > > Hi there, > > > > > > > On 22 Apr 2021, at 03:52, Trevor Vaughan <tvaughan@onyxpoint.com <mailto: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 <mailto:389-users@lists.fedoraproject.org> > > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > > > 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 <mailto:389-users@lists.fedoraproject.org> > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > > 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 <mailto:389-users@lists.fedoraproject.org> > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > > 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 <mailto:389-users@lists.fedoraproject.org> > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > > 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 <mailto:389-users@lists.fedoraproject.org> > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > > 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 <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > > _______________________________________________ > > 389-users mailing list -- 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > > _______________________________________________ > > 389-users mailing list -- 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > > _______________________________________________ > > 389-users mailing list -- 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > 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 <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> 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 <mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
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....
Do not reply to spam on the list, report it:
Interestingly, if I remove the cipher specification, I get the result of ECDHE-RSA-AES128-GCM-SHA256.
Can you see if this also happens with your version of nss?
Thanks,
Trevor
On Wed, Apr 28, 2021 at 8:27 AM Trevor Vaughan tvaughan@onyxpoint.com wrote:
So, I just ran this test with selfserv as you have above and everything worked as expected with s_client.
It seems to be something in 389 itself.
On Tue, Apr 27, 2021 at 6:32 PM Rob Crittenden rcritten@redhat.com wrote:
Trevor Vaughan wrote:
Going full circle on this, I confirmed using s_client that what I was seeing was indeed happening but not for the reason that I thought it
was.
Given that the min_ssf is 256, the connection requires a 256-bit cipher and hash to communicate with the server.
Strangely, the internal strength logic on the 389-DS side appears to pick ECDHE-RSA-AES128-GCM-SHA256 *before* ECDHE-RSA-AES256-GCM-SHA384. Likewise, if I add any of the AES128 ciphers to the list after the AES256 ciphers, one of the 128-bit ciphers will be chosen first. This seems incorrect given that the server should be using the strongest cipher suite available if possible.
The client cipher order preference is completely ignored (which is
fine).
As pointed out in the last response, I did indeed need to explicitly enable only the 256-bit+ hash/cipher combinations in the confusingly-named nsSSL3Ciphers attribute.
After figuring this out and dumping the internal supported cipher list, I can confirm that the ciphers in the nsSSL3Ciphers list are the only ones that are presented to the client.
While not ideal, this does provide a solution to the issue where I don't have to tell all system users that they need to nail up the cipher lists on the client side in order for things to function properly.
But that leaves me with two questions:
- Why, when the nsslapd-minssf option is set in the global
configuration, does 389-DS not automatically prune any options that will result in an unsuccessful connection.
- Why is the internal cipher sorting order choosing weaker cipher
suites before stronger ones?
I'm pretty sure that 389-ds still uses NSS for server-side crypto and unless something has changed NSS doesn't do cipher sorting. It picks the "best" for you. AFAIR the server has no say in the matter.
But, as a goof I used a pure NSS server tool to see what happens and it picked the expected cipher.
Enable your two ciphers (in hex form):
$ /usr/lib64/nss/unsupported-tools/selfserv -n Server-Cert -d /etc/dirsrv/slapd-EXAMPLE-TEST/ -p 8389 -f /etc/dirsrv/slapd-EXAMPLE-TEST/pwdfile.txt -c :C02F -c :C030 -v -V tls1.2:tls1.2
run s_client:
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 2AF9EFDDB3EA99C101C4E4F99A47CD479D294C15309D7E994ADA21C083D8E096 Session-ID-ctx: Master-Key:
85646A59B24D5A88080227BD59E328C688910FB0B2E2BAD77D7B1A96F6A9A3ACBF74EEC6C844A7D59527152928580743 PSK identity: None PSK identity hint: None SRP username: None Start Time: 1619562457 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: yes
So even more confusing unless I've goofed something up, sorry. I didn't mess with minssf, maybe that does make a difference.
The ciphers are:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 0xC02F TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 0xC030
Don't mean to stir up the mud but this may be a question for the NSS team.
rob
On Mon, Apr 26, 2021 at 11:50 PM William Brown <wbrown@suse.de mailto:wbrown@suse.de> wrote:
Then youll need to disable everything except aes256 then I suspect ... :( > On 25 Apr 2021, at 11:39, Trevor Vaughan <tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com>> wrote: > > 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 <mailto:wbrown@suse.de>> wrote: > > > > On 24 Apr 2021, at 22:30, Trevor Vaughan <
tvaughan@onyxpoint.com
<mailto: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 <mailto: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/ht...
> > > > 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:wbrown@suse.de>> wrote: > > > Hi there, > > > > > > > On 22 Apr 2021, at 03:52, Trevor Vaughan <tvaughan@onyxpoint.com <mailto: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 <mailto:389-users@lists.fedoraproject.org> > > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > > > 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 <mailto:389-users@lists.fedoraproject.org> > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > > 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 <mailto:389-users@lists.fedoraproject.org> > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > > 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 <mailto:389-users@lists.fedoraproject.org> > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > > 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 <mailto:389-users@lists.fedoraproject.org> > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > > 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 <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > > _______________________________________________ > > 389-users mailing list -- 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > > _______________________________________________ > > 389-users mailing list -- 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > > _______________________________________________ > > 389-users mailing list -- 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > 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 <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> 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 <mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
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....
Do not reply to spam on the list, report it:
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
As a follow up to William's suggestion of setting the global crypto policy to FUTURE:
This does work but only because the AES128 ciphers are completely removed from the global NSS policies. So it doesn't actually fix the problem, it just masks it (and who knows where else it will pop up).
On Wed, Apr 28, 2021 at 8:29 AM Trevor Vaughan tvaughan@onyxpoint.com wrote:
Interestingly, if I remove the cipher specification, I get the result of ECDHE-RSA-AES128-GCM-SHA256.
Can you see if this also happens with your version of nss?
Thanks,
Trevor
On Wed, Apr 28, 2021 at 8:27 AM Trevor Vaughan tvaughan@onyxpoint.com wrote:
So, I just ran this test with selfserv as you have above and everything worked as expected with s_client.
It seems to be something in 389 itself.
On Tue, Apr 27, 2021 at 6:32 PM Rob Crittenden rcritten@redhat.com wrote:
Trevor Vaughan wrote:
Going full circle on this, I confirmed using s_client that what I was seeing was indeed happening but not for the reason that I thought it
was.
Given that the min_ssf is 256, the connection requires a 256-bit cipher and hash to communicate with the server.
Strangely, the internal strength logic on the 389-DS side appears to pick ECDHE-RSA-AES128-GCM-SHA256 *before* ECDHE-RSA-AES256-GCM-SHA384. Likewise, if I add any of the AES128 ciphers to the list after the AES256 ciphers, one of the 128-bit ciphers will be chosen first. This seems incorrect given that the server should be using the strongest cipher suite available if possible.
The client cipher order preference is completely ignored (which is
fine).
As pointed out in the last response, I did indeed need to explicitly enable only the 256-bit+ hash/cipher combinations in the confusingly-named nsSSL3Ciphers attribute.
After figuring this out and dumping the internal supported cipher list, I can confirm that the ciphers in the nsSSL3Ciphers list are the only ones that are presented to the client.
While not ideal, this does provide a solution to the issue where I
don't
have to tell all system users that they need to nail up the cipher
lists
on the client side in order for things to function properly.
But that leaves me with two questions:
- Why, when the nsslapd-minssf option is set in the global
configuration, does 389-DS not automatically prune any options that
will
result in an unsuccessful connection.
- Why is the internal cipher sorting order choosing weaker cipher
suites before stronger ones?
I'm pretty sure that 389-ds still uses NSS for server-side crypto and unless something has changed NSS doesn't do cipher sorting. It picks the "best" for you. AFAIR the server has no say in the matter.
But, as a goof I used a pure NSS server tool to see what happens and it picked the expected cipher.
Enable your two ciphers (in hex form):
$ /usr/lib64/nss/unsupported-tools/selfserv -n Server-Cert -d /etc/dirsrv/slapd-EXAMPLE-TEST/ -p 8389 -f /etc/dirsrv/slapd-EXAMPLE-TEST/pwdfile.txt -c :C02F -c :C030 -v -V tls1.2:tls1.2
run s_client:
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 2AF9EFDDB3EA99C101C4E4F99A47CD479D294C15309D7E994ADA21C083D8E096 Session-ID-ctx: Master-Key:
85646A59B24D5A88080227BD59E328C688910FB0B2E2BAD77D7B1A96F6A9A3ACBF74EEC6C844A7D59527152928580743 PSK identity: None PSK identity hint: None SRP username: None Start Time: 1619562457 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: yes
So even more confusing unless I've goofed something up, sorry. I didn't mess with minssf, maybe that does make a difference.
The ciphers are:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 0xC02F TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 0xC030
Don't mean to stir up the mud but this may be a question for the NSS team.
rob
On Mon, Apr 26, 2021 at 11:50 PM William Brown <wbrown@suse.de mailto:wbrown@suse.de> wrote:
Then youll need to disable everything except aes256 then I suspect ... :( > On 25 Apr 2021, at 11:39, Trevor Vaughan <tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com>> wrote: > > 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 <mailto:wbrown@suse.de>> wrote: > > > > On 24 Apr 2021, at 22:30, Trevor Vaughan <
tvaughan@onyxpoint.com
<mailto: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 <mailto: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/ht...
> > > > 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
<mailto:wbrown@suse.de>> wrote: > > > Hi there, > > > > > > > On 22 Apr 2021, at 03:52, Trevor Vaughan <tvaughan@onyxpoint.com <mailto: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
<mailto:389-users@lists.fedoraproject.org> > > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > > > 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 <mailto:389-users@lists.fedoraproject.org> > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > > 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 <mailto:389-users@lists.fedoraproject.org> > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > > 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 <mailto:389-users@lists.fedoraproject.org> > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > > 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 <mailto:389-users@lists.fedoraproject.org> > > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > > 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 <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > > _______________________________________________ > > 389-users mailing list -- 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > > _______________________________________________ > > 389-users mailing list -- 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > > _______________________________________________ > > 389-users mailing list -- 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> > 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 <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> 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 <mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
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....
Do not reply to spam on the list, report it:
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
Trevor Vaughan wrote:
Interestingly, if I remove the cipher specification, I get the result of ECDHE-RSA-AES128-GCM-SHA256.
Can you see if this also happens with your version of nss?
Same as you're seeing, ECDHE-RSA-AES128-GCM-SHA256 is picked.
rob
Thanks,
Trevor
On Wed, Apr 28, 2021 at 8:27 AM Trevor Vaughan <tvaughan@onyxpoint.com mailto:tvaughan@onyxpoint.com> wrote:
So, I just ran this test with selfserv as you have above and everything worked as expected with s_client. It seems to be something in 389 itself. On Tue, Apr 27, 2021 at 6:32 PM Rob Crittenden <rcritten@redhat.com <mailto:rcritten@redhat.com>> wrote: Trevor Vaughan wrote: > Going full circle on this, I confirmed using s_client that what I was > seeing was indeed happening but not for the reason that I thought it was. > > Given that the min_ssf is 256, the connection requires a 256-bit cipher > and hash to communicate with the server. > > Strangely, the internal strength logic on the 389-DS side appears to > pick ECDHE-RSA-AES128-GCM-SHA256 *before* ECDHE-RSA-AES256-GCM-SHA384. > Likewise, if I add any of the AES128 ciphers to the list after the > AES256 ciphers, one of the 128-bit ciphers will be chosen first. This > seems incorrect given that the server should be using the strongest > cipher suite available if possible. > > The client cipher order preference is completely ignored (which is fine). > > As pointed out in the last response, I did indeed need to explicitly > enable only the 256-bit+ hash/cipher combinations in the > confusingly-named nsSSL3Ciphers attribute. > > After figuring this out and dumping the internal supported cipher list, > I can confirm that the ciphers in the nsSSL3Ciphers list are the only > ones that are presented to the client. > > While not ideal, this does provide a solution to the issue where I don't > have to tell all system users that they need to nail up the cipher lists > on the client side in order for things to function properly. > > But that leaves me with two questions: > > 1) Why, when the nsslapd-minssf option is set in the global > configuration, does 389-DS not automatically prune any options that will > result in an unsuccessful connection. > > 2) Why is the internal cipher sorting order choosing weaker cipher > suites before stronger ones? I'm pretty sure that 389-ds still uses NSS for server-side crypto and unless something has changed NSS doesn't do cipher sorting. It picks the "best" for you. AFAIR the server has no say in the matter. But, as a goof I used a pure NSS server tool to see what happens and it picked the expected cipher. Enable your two ciphers (in hex form): $ /usr/lib64/nss/unsupported-tools/selfserv -n Server-Cert -d /etc/dirsrv/slapd-EXAMPLE-TEST/ -p 8389 -f /etc/dirsrv/slapd-EXAMPLE-TEST/pwdfile.txt -c :C02F -c :C030 -v -V tls1.2:tls1.2 run s_client: New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 2AF9EFDDB3EA99C101C4E4F99A47CD479D294C15309D7E994ADA21C083D8E096 Session-ID-ctx: Master-Key: 85646A59B24D5A88080227BD59E328C688910FB0B2E2BAD77D7B1A96F6A9A3ACBF74EEC6C844A7D59527152928580743 PSK identity: None PSK identity hint: None SRP username: None Start Time: 1619562457 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: yes So even more confusing unless I've goofed something up, sorry. I didn't mess with minssf, maybe that does make a difference. The ciphers are: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 0xC02F TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 0xC030 Don't mean to stir up the mud but this may be a question for the NSS team. rob > On Mon, Apr 26, 2021 at 11:50 PM William Brown <wbrown@suse.de <mailto:wbrown@suse.de> > <mailto:wbrown@suse.de <mailto:wbrown@suse.de>>> wrote: > > Then youll need to disable everything except aes256 then I suspect > ... :( > > > On 25 Apr 2021, at 11:39, Trevor Vaughan <tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com> > <mailto:tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com>>> wrote: > > > > 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 <mailto:wbrown@suse.de> > <mailto:wbrown@suse.de <mailto:wbrown@suse.de>>> wrote: > > > > > > > On 24 Apr 2021, at 22:30, Trevor Vaughan <tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com> > <mailto:tvaughan@onyxpoint.com <mailto: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 <mailto:msauton@redhat.com> > <mailto:msauton@redhat.com <mailto: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 <mailto:tvaughan@onyxpoint.com> <mailto:tvaughan@onyxpoint.com <mailto: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 <mailto:wbrown@suse.de> > <mailto:wbrown@suse.de <mailto: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 <mailto:tvaughan@onyxpoint.com> <mailto:tvaughan@onyxpoint.com <mailto: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 <mailto:progier@redhat.com> <mailto:progier@redhat.com <mailto: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 <mailto:tvaughan@onyxpoint.com> <mailto:tvaughan@onyxpoint.com <mailto: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 <mailto:wbrown@suse.de> > <mailto:wbrown@suse.de <mailto:wbrown@suse.de>>> wrote: > > > > Hi there, > > > > > > > > > On 22 Apr 2021, at 03:52, Trevor Vaughan > <tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com> <mailto:tvaughan@onyxpoint.com <mailto: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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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 <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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 --
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
Lovely. Is this something that the 389 team is willing to take up to NSS or shall I go it alone?
Given that most things will work (if accidentally) anyone setting minssf is likely to be quite surprised.
Thanks,
Trevor
On Wed, Apr 28, 2021 at 9:24 AM Rob Crittenden rcritten@redhat.com wrote:
Trevor Vaughan wrote:
Interestingly, if I remove the cipher specification, I get the result of ECDHE-RSA-AES128-GCM-SHA256.
Can you see if this also happens with your version of nss?
Same as you're seeing, ECDHE-RSA-AES128-GCM-SHA256 is picked.
rob
Thanks,
Trevor
On Wed, Apr 28, 2021 at 8:27 AM Trevor Vaughan <tvaughan@onyxpoint.com mailto:tvaughan@onyxpoint.com> wrote:
So, I just ran this test with selfserv as you have above and everything worked as expected with s_client. It seems to be something in 389 itself. On Tue, Apr 27, 2021 at 6:32 PM Rob Crittenden <rcritten@redhat.com <mailto:rcritten@redhat.com>> wrote: Trevor Vaughan wrote: > Going full circle on this, I confirmed using s_client that what I was > seeing was indeed happening but not for the reason that I thought it was. > > Given that the min_ssf is 256, the connection requires a 256-bit cipher > and hash to communicate with the server. > > Strangely, the internal strength logic on the 389-DS side appears to > pick ECDHE-RSA-AES128-GCM-SHA256 *before* ECDHE-RSA-AES256-GCM-SHA384. > Likewise, if I add any of the AES128 ciphers to the list after
the
> AES256 ciphers, one of the 128-bit ciphers will be chosen first. This > seems incorrect given that the server should be using the strongest > cipher suite available if possible. > > The client cipher order preference is completely ignored (which is fine). > > As pointed out in the last response, I did indeed need to explicitly > enable only the 256-bit+ hash/cipher combinations in the > confusingly-named nsSSL3Ciphers attribute. > > After figuring this out and dumping the internal supported cipher list, > I can confirm that the ciphers in the nsSSL3Ciphers list are the only > ones that are presented to the client. > > While not ideal, this does provide a solution to the issue where I don't > have to tell all system users that they need to nail up the cipher lists > on the client side in order for things to function properly. > > But that leaves me with two questions: > > 1) Why, when the nsslapd-minssf option is set in the global > configuration, does 389-DS not automatically prune any options that will > result in an unsuccessful connection. > > 2) Why is the internal cipher sorting order choosing weaker
cipher
> suites before stronger ones? I'm pretty sure that 389-ds still uses NSS for server-side crypto and unless something has changed NSS doesn't do cipher sorting. It picks the "best" for you. AFAIR the server has no say in the matter. But, as a goof I used a pure NSS server tool to see what happens and it picked the expected cipher. Enable your two ciphers (in hex form): $ /usr/lib64/nss/unsupported-tools/selfserv -n Server-Cert -d /etc/dirsrv/slapd-EXAMPLE-TEST/ -p 8389 -f /etc/dirsrv/slapd-EXAMPLE-TEST/pwdfile.txt -c :C02F -c :C030 -v
-V
tls1.2:tls1.2 run s_client: New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 2AF9EFDDB3EA99C101C4E4F99A47CD479D294C15309D7E994ADA21C083D8E096 Session-ID-ctx: Master-Key:
85646A59B24D5A88080227BD59E328C688910FB0B2E2BAD77D7B1A96F6A9A3ACBF74EEC6C844A7D59527152928580743
PSK identity: None PSK identity hint: None SRP username: None Start Time: 1619562457 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: yes So even more confusing unless I've goofed something up, sorry. I didn't mess with minssf, maybe that does make a difference. The ciphers are: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 0xC02F TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 0xC030 Don't mean to stir up the mud but this may be a question for the NSS team. rob > On Mon, Apr 26, 2021 at 11:50 PM William Brown <wbrown@suse.de <mailto:wbrown@suse.de> > <mailto:wbrown@suse.de <mailto:wbrown@suse.de>>> wrote: > > Then youll need to disable everything except aes256 then I suspect > ... :( > > > On 25 Apr 2021, at 11:39, Trevor Vaughan <tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com> > <mailto:tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com>>> wrote: > > > > 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 <mailto:wbrown@suse.de> > <mailto:wbrown@suse.de <mailto:wbrown@suse.de>>> wrote: > > > > > > > On 24 Apr 2021, at 22:30, Trevor Vaughan <tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com> > <mailto:tvaughan@onyxpoint.com <mailto: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 <mailto:msauton@redhat.com> > <mailto:msauton@redhat.com <mailto: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/ht...
> > > > > > 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 <mailto:tvaughan@onyxpoint.com> <mailto:tvaughan@onyxpoint.com <mailto: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 <mailto:wbrown@suse.de> > <mailto:wbrown@suse.de <mailto: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 <mailto:tvaughan@onyxpoint.com> <mailto:tvaughan@onyxpoint.com <mailto: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 <mailto:progier@redhat.com> <mailto:progier@redhat.com <mailto: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 <mailto:tvaughan@onyxpoint.com> <mailto:tvaughan@onyxpoint.com <mailto: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 <mailto:wbrown@suse.de> > <mailto:wbrown@suse.de <mailto:wbrown@suse.de>>> wrote: > > > > Hi there, > > > > > > > > > On 22 Apr 2021, at 03:52, Trevor Vaughan > <tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com> <mailto:tvaughan@onyxpoint.com <mailto: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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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....
> > > > > 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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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....
> > > > 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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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....
> > > > 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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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....
> > > > 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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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....
> > > > 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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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....
> > > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > > > _______________________________________________ > > > 389-users mailing list -- 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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....
> > > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > > > _______________________________________________ > > > 389-users mailing list -- 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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....
> > > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > > > _______________________________________________ > > > 389-users mailing list -- 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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....
> > > 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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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....
> > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > > _______________________________________________ > > 389-users mailing list -- 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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....
> > 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 <mailto:389-users@lists.fedoraproject.org> > <mailto:389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>> > To unsubscribe send an email to > 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > <mailto:389-users-leave@lists.fedoraproject.org <mailto: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....
> 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 <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto: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....
> 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
--
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
389-users@lists.fedoraproject.org