Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777

[John Haxby <john.haxby () oracle com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/03/15 01:02, Kurt Seifried wrote:
> Please contact your TAM/GSS with this request, it carries a lot
> more impact if customers want something that we also want.


I know "me too" isn't helpful, but I'm going to say "me too" anyway.


> On 05/03/15 04:09 PM, Michael Samuel wrote:
> > Could RedHat ship a new package that replaced python's default
> > SSL library with the one that validates TLS by default and
> > release a RHEA?
> >
> > That way customers (like me) who never want broken TLS on their 
> > network can just install a package and it's fixed.


It occurred to me that we could have a patch that has a global switch
(eg a file in, say, /etc/sysconfig and a corresponding switch for
individual applications) that switches on the correct behaviour.   I
know it's a bit of a mess, but that way people who don't care will
continue in blissful ignorance and people that do care can do
something about it.

jch


> > Regards, Michael
> >
> > On 6 March 2015 at 05:36, Kurt Seifried <kseifried () redhat com>
> > wrote:
> > > On 05/03/15 10:06 AM, John Haxby wrote:
> > > > PEP 476 cites 11 CVEs that resulted from python not properly
> > > > validating certificates.   This would be number 12.
> > > >
> > > > Shouldn't python versions prior to 2.7.9 and 3.4.3 have a CVE
> > > > each for the lack of verification? If internal corporate
> > > > software stops working because of invalid certificates,
> > > > wasn't it broken anyway?
> > >
> > > So if something is advertised as having a security feature and
> > > does not or it is broken then it gets a CVE. In this case
> > > Python, and basically every other SSL/TLS implementation on the
> > > planet, by default, did not check hostnames in certs, but they
> > > did provide that capability should you choose to use it. So no
> > > CVE since it wasn't "meant to be secure" as I understand it.
> > >
> > > Now for my personal opinion: Doing SSL/TLS with server certs
> > > and not checking the hostname in a server cert is completely
> > > insane and utterly defeats the purpose. However there are cases
> > > where a certificate may not have a hostname field, or need a
> > > valid hostname field, e.g. a client certificate where you
> > > mostly care about the fact that the client has it at all. So I
> > > can see why they made hostname checks optional, but again, I
> > > think it was a very bad decision long term as evidenced by:
> > >
> > > http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=certificate+hostname+check
> > >
> > > >
jch
> > > >
> > >
> > > -- Kurt Seifried -- Red Hat -- Product Security -- Cloud PGP
> > > A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iF4EAREIAAYFAlT5pt8ACgkQRQu7fpQvo8iXBQD+Ndbpfs/q86yN+KxS/pkPd2bB
YoV1Dqx3bnVq8s5kD3cA/japMu5aO2C4KMlTojUn50vuKNM0rT8kWC4xoaKBGrPF
=FL48
-----END PGP SIGNATURE-----