On Tue, 2017-11-07 at 14:21 +0100, Matus Honek wrote: > 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@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
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
