Re: Raise MIN TLS to 1.2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Fedora Directory Announce]     [Fedora Users]     [Older Fedora Users Mail]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Review]     [Fedora Art]     [Fedora Music]     [Fedora Packaging]     [CentOS]     [Fedora SELinux]     [Big List of Linux Books]     [KDE Users]     [Fedora Art]     [Fedora Docs]

  Powered by Linux