On Tue, 2017-11-07 at 14:21 +0100, Matus Honek wrote:
William Brown <wibrown(a)redhat.com> writes:
> Hi there,
>
> For 1.4 I would like to raise MINTLS level to 1.2. This should be a
> safe change for us to make, and clients with affected clients that
> need
> less can easily downgrade this.
>
> I'm invested in secure by default, so I think this is important to
> do.
>
>
https://pagure.io/389-ds-base/issue/49395
>
> To put this in perspective, java 7 supports TLS 1.2 since 2011 and
> most
> major operating systems have supported it since 2008 and onwards.
> There
> is no reason to hold this back at 1.0 or 1.1.
>
> I would like this reviewed and acked soon, so this is the chance to
> comment now please,
>
>
>
> --
> Sincerely,
>
> William Brown
> Software Engineer
> Red Hat, Australia/Brisbane
> _______________________________________________
> 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject
> .org
Hi,
first, I'm all in for increasing the defaults and currently TLSv1.2
as a default makes complete sense to me for 1.4 branch.
Great! Thank you!
Second, I've noticed some extensive 'if'-tree in the code for
selecting
the right version. Although I did not go thru the code to understand
it
entirely, I noticed (or maybe just missed?) that we do not yet
implement
some new API NSS provides in this area. One thought I had was why not
use SSL_VersionRangeGetDefault to dynamically get sane "default" [1]
expectations from the crypto library itself and use them for our
default
(e.g. set our default TLS min to "NSS default max" - 1, that is the
top
two versions). Not exactly this way but I made a use of this API in
OpenLDAP [2]. With properly logging the behaviour this would not look
like a magic and still would track the TLS development
automatically. With the current state, having the min version
hardcoded
still makes one to check in what version of 389ds what TLS version
was
the set default. The described way, this would to be checked in the
logs.
Also, we probably do not want the NSS"supported max" to be our
supported
max, as it would just make use of (most probably buggy) unfinished
implementations of TLS. Thus, our supported max should be set to NSS'
default max.
I think these are both excellent points! Can you please open pagure
tickets related to these then?
[1] Note, the "default" is a subset of "supported" (so, e.g.
supported
(and partially usable) has been TLSv1.3 for quite some time but it
got
to be default just recently).
[2]
https://src.fedoraproject.org/rpms/openldap/blob/32c688fc277292ef
000ec087dfb892419a732daa/f/openldap-nss-protocol-version-new-
api.patch
2c.
--
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane