On 7/17/19 11:47 PM, William Brown wrote:
On 17 Jul 2019, at 22:36, Mark Reynolds <mreynolds@xxxxxxxxxx> wrote:
On 7/17/19 3:01 AM, Matus Honek wrote:
I think we cannot remove it. Setting the MIN version is a workaround
for *old clients* not even supporting current NSS' default min.
Setting up MAX version is a workaround for *broken clients* thinking
they can support something they announced but for some reason fail to
work with such a version. I believe most of deployments have some
really legacy software of which not a small amount behaves weirdly
enough these two options save lives; I have seen these issues several
times.
Did you see anyone still using SSL3?
The min is good to allow a sysadmin to clamp the min version up to something like TLS1.2 rather than TLS 1.0 and 1.1 which both have known issues.
So Ithink we should leave this, but default to the NSS system wide crypto, and document and advise to use NSS systemd wide crypto policy instead.
Well the bug I have is now is the NSS system wide policy is overriding
min and max ssl versions and always using (min TLS 1.2 -> max TLS 1.3).
Looks like if you try and use SSL3 it just overrides it in the current
version of NSS anyway. So I am probably going to remove all the SSL3
specific code in ssl.c. But I'll keep the min and max settings...
On Tue, Jul 16, 2019 at 10:24 PM Mark Reynolds <mreynolds@xxxxxxxxxx> wrote:
So some time ago when the poodlebleed vulnerability came out in SSL3 we
added a way to set the minimum and maximum SSL/TLS versions the server
would accept (e.g. TLS1.1 <--> TLS1.2). Current versions of NSS
already use this range by default. I would like to remove/deprecate the
sslVersionMin/Max and just use what NSS uses by default (which should be
the system wide crypto policy).
Is anyone actually using sslVersionMin/Max? Do we really have a need
for it anymore?
--
389 Directory Server Development Team
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
--
389 Directory Server Development Team
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
--
389 Directory Server Development Team
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
