SecureApt for Proxmox 5/4 on debian 9/8

[jaydee]

Hello,

This is my first post on this forum. I hope I'm following expected behavior with the following question.


Questions:
I'm posting this thread because I'm wondering why:
1°) when installing proxmox on debian, one does not seem to have other options than download the secure apt signature verification key in http instead of https
see proxmox 4 on debian 8: https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Jessie
see proxmox 5 on debian 9: https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Stretch
see section 3.1.4 Secure Apt: https://pve.proxmox.com/pve-docs/pve-admin-guide.html

this could be an open door to MitM attacks. Impact of this attack could be complete compromise of the hypervisor by pushing compromised updates executed with root privileges (i.e. full control of everything).

Simply replacing "http" by "https" in the tutorial does not solve the issue. The certificate that is afterwards recovered during the TLS exchange
1°) is for another domain
2°) if accepted leads to an authentication request (paid subscription)

2°) when following both guides for proxmox 4 on debian 8 and proxmox 5 on debian 9, there is no indication of any way to check if the key that one installs to verify packages is the correct one.
see proxmox 4 on debian 8: https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Jessie
see proxmox 5 on debian 9: https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Stretch

Some people might simply blindly follow the tutorial (for which I'm grateful. I have not tested the pve5 on debian9 yet, but the other one works like a charm and I thank every contributor for that) and thus,
this could be an open door to MitM attacks. Impact of this attack could be complete compromise of the hypervisor by pushing compromised updates executed with root privileges (i.e. full control of everything).

It is however possible to dig deep into proxmox's website and look for the fingerprint.

However,
a) I cannot manage to find pve4's fingerprint anymore
b) pve5's can be found here: https://pve.proxmox.com/pve-docs/pve-admin-guide.html
c) but this seems to be a poor approach to security as I'm not convinced most people will look that far and the page could be deprecated, erroneous, etc.

3°) when reading the only information I've managed to find in https to check pve5's key, the checksum is provided using and md5 hash which has been considered cryptographically insecure for very long now.
see section 3.1.4 Secure Apt: https://pve.proxmox.com/pve-docs/pve-admin-guide.html


Suggestions:
A potential solution to this "questions" might be to update the 3 pages:
see proxmox 4 on debian 8: https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Jessie
see proxmox 5 on debian 9: https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Stretch
see section 3.1.4 Secure Apt: https://pve.proxmox.com/pve-docs/pve-admin-guide.html

and include instructions in all three to verify the key's fingerprint and SHA512SUM.

What do you think?

Kind regards,

J.

 

[LnxBil]

Thank you for bringing this to our attention.

What do you think?

The current situation can be interpreted as follows:

Buy a subscription and use the secure way or you're on your own (as you are without a support subscription). Maybe this is intentionally.

 

[dietmar]

See: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_secureapt

# md5sum /etc/apt/trusted.gpg.d/proxmox-ve-release-5.x.gpg
511d36d0f1350c01c42a3dc9f3c27939 /etc/apt/trusted.gpg.d/proxmox-ve-release-5.x.gpg

The wiki page also contains this information:

https://pve.proxmox.com/wiki/Package_Repositories

 

[jaydee]

Apparently I was not clear. I appologize for the confusion. I'll try a last time to make myself clearer.

Dietmar> this is the information I'm referring to in point 2.b.
Dietmar> Your answer do not answer any of the questions.
Question1: why no https (TLS) to download the keys?
Question2: why is there no mention of at least a cryptographically secure hash on any of the "install proxmox on debian" wiki page available in https?
Question3: why rely on a md5sum hash that is considered in 2017 as cryptographically insecure instead of using SHA512 for example?

If answers to 1, 2 and 3 are "yes, doing so looks like an improvement!"
then my suggestion was:
update the 3 pages:
see proxmox 4 on debian 8: https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Jessie
see proxmox 5 on debian 9: https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Stretch
see section 3.1.4 Secure Apt: https://pve.proxmox.com/pve-docs/pve-admin-guide.html

and include instructions in all three to verify the key's fingerprint and SHA512SUM.

Is that more understandable? If not, accept my apologies, I was merely trying to contact the proxmox team/community to improve the overall security.

 

[jaydee]

P.S.: these are merely questions. There might be a good reason for all this and I might be unaware of it.
For instance, the ISOs are provided with a sha256 (https://www.proxmox.com/en/downloads (the hashes can be found on individual download pages).) which is already an improvement compared to md5 that one can look for and search within the documentation and then find as mentioned in my first post in section 3.1.4 Secure Apt https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_secureapt.
However, other distributions such as debian (cdimage.debian.org/debian-cd/current/amd64/iso-cd/) that the guide on the wiki refers to are providing SHA512 hashes (cdimage.debian.org/debian-cd/current/amd64/iso-cd/SHA512SUMS) and digital signatures (cdimage.debian.org/debian-cd/current/amd64/iso-cd/SHA512SUMS.sign) for their iso. Kali is also provided using digital signatures kali.org/downloads/ and instructions to verify the signature on the download page etc.
So I was wondering for what particular reason there seems to be an apparent lower level of security (but maybe not?) for proxmox. And I insist, I might be wrong hence the question.

 

[LnxBil]

Question3: why rely on a md5sum hash that is considered in 2017 as cryptographically insecure instead of using SHA512 for example?

Because it is still practically very, very hard (if not impossible) to construct another GPG-Key that has the same MD5 checksum. MD5 was considered broken in 2006 when the first real world examples arised for forged documents having the same MD5 checksum, yet MD5 is still in use for very small files down to passwords because there is no way yet to create or predict a collision for the same input size. Therefore, the likelihood of having a compromised GPG key having the same MD5 hash is very, very improbable.

But besides any of these remarks, if the website would be hacked, an intelligent hacker would change everything including the GPG key, so that any security comes down to manually accepting the GPG key as long as you haven't reviewed the fingerprint with a valid source like it is normal with GPG and actual human beeings. This initial dilemma cannot be solved because you have to trust someone if you want to rely on any of these techniques.

providing SHA512 hashes [...] and digital signatures [..] for their iso.

Yes, I wondered about the same thing. Would be great to have these at hand.

 

[jaydee]

Regarding question 3:

Because it is still practically very, very hard (if not impossible) to construct another GPG-Key that has the same MD5 checksum. MD5 was considered broken in 2006 when the first real world examples arised for forged documents having the same MD5 checksum, yet MD5 is still in use for very small files down to passwords because there is no way yet to create or predict a collision for the same input size. Therefore, the likelihood of having a compromised GPG key having the same MD5 hash is very, very improbable.

I do get and agree with you that an md5 attack on the key would be difficult to perform. However,
1°) there are available implementations of cryptographic hash functions such as SHA512 that are considered more secure and using them instead does not increase any cost (IMHO), hence my question. Why continue to use MD5 for the GPG key?
2°) these implementation seems to be available to the proxmox team since the installation ISO are hashed with SHA256 and not MD5, hence my question. Why continue to use MD5 for the GPG key?

 

[Denny]

You always have the option of using apt-cacher or spacewalk for managing your packages. Then you can inspect to your hearts content before deploying to production.


Edited to change apt-cache to apt-cacher

 

[dietmar]

Why continue to use MD5 for the GPG key?

I personally still prefer MD5, because it is relatively short and easy to compare manually. But I now added
the SHA512 also:

https://pve.proxmox.com/wiki/Package_Repositories#_secureapt

 

[jaydee]

great, thx dietmar.
Any chances that the 2 guides (pve4 on deb8 and pve5 on deb9) might be updated or at least a sentence "we invite you to verify the hash of the key as shown there: https://pve.proxmox.com/wiki/Package_Repositories#_secureapt"?
Again, it's not for me. I did know it was important to verify the hash of the key and I did find the hash. But others might simply skip that part being unaware of the importance of verifying the integrity of the key they are installing on their server.