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 <john.haxby@...cle.com>
To: oss-security@...ts.openwall.com
Subject: Re: Another Python app (rhn-setup: rhnreg_ks) not
 checking hostnames in certs properly CVE-2015-1777

-----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@...hat.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-----

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