Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 06 Mar 2015 13:08:58 +0000
From: John Haxby <>
Subject: Re: Another Python app (rhn-setup: rhnreg_ks) not
 checking hostnames in certs properly CVE-2015-1777

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.


>> Regards, Michael
>> On 6 March 2015 at 05:36, Kurt Seifried <>
>> 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:
>>> -- Kurt Seifried -- Red Hat -- Product Security -- Cloud PGP
>>> A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

Version: GnuPG v1


Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ