Date: Thu, 12 Mar 2015 16:41:19 +1100 From: Michael Samuel <mik@...net.net> To: oss-security@...ts.openwall.com Subject: Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777 On 12 March 2015 at 15:43, Kurt Seifried <kseifried@...hat.com> wrote: > If your SSL/TLS implementation accepts expired certs as being ok, then > you have a problem. Sure thing, test for it then if you like. Just install an expired cert on a test server and connect. But if I logged it against a RedHat product, I'd put it as a bug, not security issue. >>> What about a certificate signed for the correct hostname by a system >>> trusted CA? (some apps are supposed to only trust a specific CA). >> >> That's a policy bug too, not an easily exploitable security bug >> (unless one of your >> system CAs is compromised). Does RedHat actually ship anything that >> does pinning? > > That's a real world bug. Logic error "trust properly signed cert" vs. > "trust specific CA signed cert". Ok, but if somebody's implemented this feature they've gone well beying the point of not verifying certificates at all, which is what pretty much every program I tested that ships with RHEL did until I logged bugs against them. Apache still doesn't validate certificates for backend connections in RHEL (mod_proxy). > Uhm. Did you not look at any of the cve.mitre.org links I sent? These > are incredibly common failures. Hint: if some class of bug has a bunch > of CVE's you can multiply it by 100 or more for the number of affected > real world cases (and that's in English software alone). If you think they're common, ask your dev teams test for them before shipping. > Anyways I think we're sufficiently off topic now. I think this is an important discussion to have, and I don't think we're at all off topic (for the list or thread). I know TLS is hard, but we don't have to default to snake-oil bad. Regards, Michael
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ