----- Original Message -----
From: "Sven Kieske" <s.kieske@mittwald.de> To: "Simone Tiraboschi" <stirabos@redhat.com> Cc: users@ovirt.org Sent: Tuesday, March 10, 2015 11:12:38 AM Subject: Re: [ovirt-users] Error during hosted-engine-setup for 3.5.1 on F20 (Cannot add the host to cluster ... SSH has failed)
On 10/03/15 10:53, Simone Tiraboschi wrote:
In order to trust an https connection to the engine you have to trust its CA but you still don't know it cause it's a private one and it has been just created on the engine from scratch.
Can't the setup display the necessary parameters to make sure I trust the right CA when I accept it in my browser? It could even create a consumable file, which I can copy to my workstation and import there.
This is another things: having the user explicitly trusting the CA cert by manually and explicitly checking its fingerprint on both the host is the right solution but is more invasive and a lot of user is already complaining that hosted-engine involves to many steps.
Blindly downloading the engine CA cert and blindly trusting it is not that different that simply using http to download the public key:
this is correct, but who would do this? of course you need to check if it is the right CA!
in order to fetch it you don't need to send any password or token and being a public key you don't need to crypt it by definition so you don't need encryption.
this is not about keeping the public key secret, but about keeping the channel over which it is transferred secure. so no one can tamper with the key and send you another public key to a different machine. (dns spoofing, arp spoofing etc.)
if you don't check the public key and ensure you connect to the correct machine, there is no need for public keys anyway and you could just skip this step.
imho this is a security bug. other people would just consider this a hardening. trusting the local network is a security mindset from the 90's.
No, I didn't said that I trust the network to be secure cause it's a local network. I said another thing, please read it carefully and follow me: 1. in order to trust an https connection you need to trust the CA that signed the cert that the engine host is using. 2. that CA is by default a private CA and so it has just been created on engine VM, so you don't have the CA cert on the host 3. so, to trust the https connection, you need to have/download the CA cert from the engine VM to the host 4. if you just download engine CA via http (https is not more secure at this point cause you are still trusting everything cause you don't have the CA cert) you just moved the issue instead of solving it So the issue is that the CA cert should reach the host in secure way otherwise you are in the same situation: somebody could provide a tampered CA cert and make you trusting a tampered https connection. It's just false security: it simply adds complexity without adding real security. I would be different if we ask to the user to copy and paste the engine CA cert by himself or at least to validate its fingerprint, without that step its really the same.
most LANs have to many hosts which you might don't even know.
you could also be on some shared foreign network where third party machines from different users can tamper with the network. I have seen user reports who used some leased hardware in offsite data centers to install ovirt, where you can't fully trust all local clients.
this should be more secure by default imho.
-- Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen