William Brown <wibrown@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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. 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. [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/32c688fc277292ef000ec087dfb892419a732daa/f/openldap-nss-protocol-version-new-api.patch 2c. -- Matus Honek Associate Software Engineer Red Hat Czech _______________________________________________ 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
