[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5500D8D9.1020405@redhat.com>
Date: Wed, 11 Mar 2015 18:07:53 -0600
From: Kurt Seifried <kseifried@...hat.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
On 03/11/2015 05:44 PM, Michael Samuel wrote:
> On 12 March 2015 at 02:48, Kurt Seifried <kseifried@...hat.com> wrote:
>
>> Much like /tmp issues the solution that will save us is not to fix every
>> /tmp issue but rather do more intelligent things like poly instantiated
>> tmp or systemd per process tmp. Sadly I don't see such an easy
>> possibility with TLS/SSL, but if we have a decent test
>> framework/reproduction ability it will make finding, fixing and
>> verifying these things a whole lot easier long term.
>
> You can test for the common bugs extremely easily - you need two types of
> bogus certificate installed on the server:
> - A completely untrusted (eg. self-signed) certificate
> - A certificate signed by a trusted authority but for the wrong hostname
If only it were so simple. Seriously, life would be awesome.
What about expired certificates?
What about certificates that are properly signed but not yet valid?
What about a certificate signed for the correct hostname by a system
trusted CA? (some apps are supposed to only trust a specific CA).
These are all very common issues.
But those would never happen right?
http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=expired+certificate
But we're also dealing with bad guys right? If we assume they can man in
the middle we have to assume they are at least semi competent (e.g. they
know how to run Tapioca or nogotofail).
So what about mangled certs that make the system go all wibbly wobbly?
That never happens right?
http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=invalid+certificate
And then on the more complicated/operational side:
What about intermediate certificate issues/chains/etc?
What about weak protocols?
What about weak ciphers?
What about weak keys?
What about specifically bad keys (https://wiki.debian.org/SSLkeys)?
What about overly broad certs used by interceptors (like *.com, *.*)
What about checking certificate constraints?
http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=intermediate+certificate
http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=certificate+constraints
FREAK, etc.
And those are just off the top of my head. There's a whole deep rabbit
hole full of angry ... things. I don't know because I don't want to
stick my head into it.
Also we'll conveniently ignore the CA issues. Diginotar et al.
Properly testing this even to a half hearted degree is very non trivial.
And if you talk to people that actually know SSL/TLS (I just pretend to
understand it) ... well if you've ever seen a train wreck in slow motion
you know what it's like.
> It's not too hard to test SSH connections in a similar manner (just regen the
> ssh host keys after the first connection).
Again if only it were so simple.
http://www.cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ssh+key
> Alternatively, you could make your OpenSSL modules for various languages
> return client ctxs that verify by default - the topic of this discussion :)
Yeah, the problem is API/ABI compatibility. Again, Red Hat has to
support software we have never seen, and will never see.
> Regards,
> Michael
>
--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
