|Summary:||CVE-2014-8164 CFME: http.verify_mode = OpenSSL::SSL::VERIFY_NONE|
|Product:||[Other] Security Response||Reporter:||Kurt Seifried <kseifried>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED DEFERRED||QA Contact:|
|Version:||unspecified||CC:||apatters, bdunne, dajohnso, dclarizi, gmccullo, jfrey, jhenner, jprause, jrafanie, jrusnack, jvlcek, kseifried, mpovolny, obarenbo, security-response-team, xlecauch|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-06-30 20:28:41 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||1151209, 1151210|
Description Kurt Seifried 2014-10-09 19:25:03 UTC
CloudForms: http.verify_mode = OpenSSL::SSL::VERIFY_NONE From the email: Ok so two main things here, firstly I would prefer to fix this all at once, looking at the code there's a whole bunch of instances of "http.verify_mode = OpenSSL::SSL::VERIFY_NONE" (11 or so out of 17 total calls for http.verify), so even if we fix this default one, there would still be the 11 instances, so rather than do several fixes and end up with multiple CVE's I'd rather do this all at once. Now as how to fix it: 1) removing any uneeded code with respect to this SSL stuff (apparently a few may not be needed anymore?) 2) By default change it so that we check SSL correctly, however for backwards compatibility of existing installations, and for demos we want to allow the old behaviour, so some switch in a config file/web interface like "Allow self signed certs" with a warning/explanation. 3) To protect against attacks (e.g. with a self signed cert, we can't check it properly, so a man in the middle attack is pretty easy) we could harden it by caching the certificates the first time we see them, and then checking against that cached copy. So in theory the first time you access it (right after setup) is safe, we cache that, and in future any changes would cause an alarm, basically buying us most of what you would get by using a "Real" certificate. So I would say #2 is mandatory, #1 is always good (removing dead code) and #3 would be very nice to have, but really if people want security they can buy certificates for not much money.
Comment 2 Kurt Seifried 2015-06-30 20:28:41 UTC
This has been deferred for now. One challenge is to enable certificate host name checking this customers will require a large number of valid host certificates. This is difficult for many customers due to the use of internal hosts, as such enabling host name checks by default will break many installs.