Description of problem: We've a customer getting Medium vulnerability on the Red Hat Virtualization Manager as 'HSTS missing From HTTPS server (RFC 6797)' and the recommendation for the same is given as 'Configure the remote web server to use HSTS' We found below KCS Topic: How to enable HTTP Strict Transport Security (HSTS) on Apache HTTPD URL: https://access.redhat.com/solutions/1220063 We want to confirm, can we refer the above mentioned KCS for the Red Hat Virtualization Manager as well? Will there be any other effect on the Manager's functionality? Version-Release number of selected component (if applicable): Red Hat Enterprise Linux Server release 7.8 (Maipo)
This is also breaking hosted-engine deploy [1]: 04:19:13 [ INFO ] TASK [ovirt.ovirt.engine_setup : Check if Engine health page is up] 04:19:14 [ ERROR ] fatal: [localhost -> lago-he-basic-suite-master-engine.lago.local]: FAILED! => {"attempts": 30, "changed": false, "content": "", "elapsed": 0, "msg": "Status code was -1 and not [200]: Request failed: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:897)>", "redirected": false, "status": -1, "url": "http://localhost/ovirt-engine/services/health"} See [2] for last successful run http access_log. It's not just the health page - we have more work there. [1] https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/1930/ [2] https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/lastSuccessfulBuild/artifact/exported-artifacts/test_logs/he-basic-suite-master/post-012_local_maintenance_sdk_pytest.py/lago-he-basic-suite-master-engine/_var_log/httpd/access_log/*view*
(In reply to Yedidyah Bar David from comment #3) > This is also breaking hosted-engine deploy [1]: > > 04:19:13 [ INFO ] TASK [ovirt.ovirt.engine_setup : Check if Engine health > page is up] > 04:19:14 [ ERROR ] fatal: [localhost -> > lago-he-basic-suite-master-engine.lago.local]: FAILED! => {"attempts": 30, > "changed": false, "content": "", "elapsed": 0, "msg": "Status code was -1 > and not [200]: Request failed: <urlopen error [SSL: > CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:897)>", > "redirected": false, "status": -1, "url": > "http://localhost/ovirt-engine/services/health"} > > See [2] for last successful run http access_log. It's not just the health > page - we have more work there. > > [1] > https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/1930/ > > [2] > https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/ > lastSuccessfulBuild/artifact/exported-artifacts/test_logs/he-basic-suite- > master/post-012_local_maintenance_sdk_pytest.py/lago-he-basic-suite-master- > engine/_var_log/httpd/access_log/*view* That does not look good. IMO it is absolutely fine to exclude health calls from 'upgrading' to https but there are just to many api calls. (...) 127.0.0.1 - - [22/Feb/2021:03:49:52 +0100] "GET /api/v1/playbooks/5e65fff4-74b8-11eb-8a79-5452c0a8c863 HTTP/1.1" 200 874 "-" "Apache-HttpClient/4.5.13 (Java/11.0.9.1)" (...) 127.0.0.1 - - [22/Feb/2021:03:50:20 +0100] "GET /api/v1/jobs/5e65fff4-74b8-11eb-8a79-5452c0a8c863/events HTTP/1.1" 200 87782 "-" "Apache-HttpClient/4.5.13 (Java/11.0.9.1)" 127.0.0.1 - - [22/Feb/2021:03:50:20 +0100] "GET /api/v1/jobs/5e65fff4-74b8-11eb-8a79-5452c0a8c863/events/468-9d204c56-c09e-4ead-baab-1d12e774e195 HTTP/1.1" 200 15458 "-" "Apache-HttpClient/4.5.13 (Java/11.0.9.1)" 127.0.0.1 - - [22/Feb/2021:03:50:20 +0100] "GET /api/v1/jobs/5e65fff4-74b8-11eb-8a79-5452c0a8c863/events/468-9d204c56-c09e-4ead-baab-1d12e774e195 HTTP/1.1" 200 15458 "-" "Apache-HttpClient/4.5.13 (Java/11.0.9.1)" 127.0.0.1 - - [22/Feb/2021:03:50:20 +0100] "GET /api/v1/jobs/5e65fff4-74b8-11eb-8a79-5452c0a8c863/events/469-5452c0a8-c863-15c3-a08b-000000000474 HTTP/1.1" 200 1169 "-" "Apache-HttpClient/4.5.13 (Java/11.0.9.1)" (...) With my very limited understanding of HE code area I'm leaning towards to revert HTST patch and think about if/how to migrate api calls to HTTPS. Second option would be allowing all http calls to localhost ... not yet sure if that's safe enough to satisfy this particular BZ. @Stoyan, perhaps you might have some opinion on the latter ?
How about, instead, using HTTPS for connections from localhost but skipping peer certificate verification as an intermediate solution? If the customer is asking for HSTS and HTTP calls of any sort are allowed that does not seem right to me.
There are two issues here, IMO: 1. Whether this should be mandatory or optional, turned on by default or not, can easily be toggled, etc. Just the same way we have code (in hosted-engine deployment) that currently uses http and fails with HSTS, it's very reasonable that other users/customers have such code - not all access is using plain browsers. 2. Whether exceptions should be allowed or not, and if yes, which ones. For https access to the engine, you need the ca cert. How to get the CA cert? One way is using the api. To do this using the api you need to access it - either with http (if we allow exceptions) or with https (and do not verify the connection, as you do not have the cert yet). (In reply to Stoyan Nikolov from comment #5) > How about, instead, using HTTPS for connections from localhost but skipping > peer certificate verification as an intermediate solution? That's definitely a reasonable intermediate solution, but also this takes time. > If the customer is asking for HSTS and HTTP calls of any sort are allowed > that does not seem right to me. So your answer to (2.) is "do not allow http access even for getting the ca cert". So we need to either use insecure non-validated https, or other means (e.g. ssh).
If the idea is to use HSTS to prevent an attacker from being able to MITM the connection then allowing for certificate retrieval in an insecure way where the attacker might be able to control what certificate is supplied defeats the purpose imho.
Maybe it should be optional. (well, I do not see much of a value in HSTS anyway) We can enable it only after deployment - would that resolve HE deployment issues easily? And if it's an optional task after installation then the convenient CA retrieval is also somewhat resolved...
(In reply to Michal Skrivanek from comment #8) > Maybe it should be optional. (well, I do not see much of a value in HSTS > anyway) > > We can enable it only after deployment - would that resolve HE deployment > issues easily? And if it's an optional task after installation then the > convenient CA retrieval is also somewhat resolved... That would work I guess(but I might be missing something outside of the engine's domain). What would be the recommended way to enabled it: engine-setup or some dedicated cmd tool? Setting HSTS requires restarting httpd afaik.
*** Bug 1933701 has been marked as a duplicate of this bug. ***
Moving to 4.5, it seems like a change with many sideeffects
Verified on: rhv-4.5.0.6-0.7.el8ev RHV environment sane and automation flow passed and behaved as expected after HSTS enabled (as described in: https://access.redhat.com/solutions/1220063)
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: RHV Manager (ovirt-engine) [ovirt-4.5.0] security update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:4711
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days