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

[Michael Samuel <mik () miknet net>]

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.

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