Bad certificate for https://download.proxmox.com/

[Machine Manager]

The non-subscription repository has a bad certificate, and it prevents HTTPS usage on `apt` related commands.

The issue is caused because it uses a certificate that is not valid for download.proxmox.com. The certificate is only valid for the following names: au.cdn.proxmox.com, de.cdn.proxmox.com, enterprise.proxmox.com, fr.cdn.proxmox.com, na.cdn.proxmox.com, sg.cdn.proxmox.com

 

[leesteken]

I think that's on purpose. The Proxmox manual only uses HTTPS for the enterprise repository, all other repositories use HTTP.

 

[sterzy]

Hi,

please also be aware that our apt repos come signed with our GPG keys anyway, so realistically adding HTTPS on top of that does not provide much of a security benefit.

The reason we use it for the enterprise repos is that you need to authenticate yourself there to prove you have a valid subscription. HTTPS is used there to protect those credentials.

 

[Neobin]

See also:
https://forum.proxmox.com/threads/repo-over-https.125882

 

[leesteken]

please also be aware that our apt repos come signed with our GPG keys anyway, so realistically adding HTTPS on top of that does not provide much of a security benefit.

Would HTTPS not protect me from my ISP watching what versions of which packages I download or throttling our connection? I can use a VPN to protect me by mixing my data with others but HTTPS not is only about authentication and data integrity, it's also about privacy against entities that see the bytes passing by. I don't care much about this at moment but it would be nice.

 

[Dunuin]

Maybe that is for all those people that finally decide to update after a decade but they are running so outdated PVEs that they can't even use SSL anymore because the local certificates are outdated. Encountered that sometimes when working with Win98/Win2000 hosts...

If it adds additional security or not, I still would like to see an option for SSL in 2023. Not that I wouldn't trust the Proxmox team that they always have security in mind when doing stuff. But a company not offering SSL isn't looking good for the public image.

 

[sterzy]

Would HTTPS not protect me from my ISP watching what versions of which packages I download or throttling our connection? I can use a VPN to protect me by mixing my data with others but HTTPS not is only about authentication and data integrity, it's also about privacy against entities that see the bytes passing by. I don't care much about this at moment but it would be nice.

As pointed out in the linked thread:

there's also no point in hiding the contents, since even with TLS, the size of the downloads are trivial to analyze and map back to the packages that are being installed.

- fabian

Keep in mind that your ISP will also see the IP address of the host you are making the request to regardless of which TLS version is being used. Also, only fairly recent TLS versions support Encrypted ClientHello (ECH). Even that only provides indistinguishability between different origin servers behind a single ECH service provider (e.g., a CDN supporting ECH) and may fall prey to similar techniques as described by Fabian.

Also: I'd argue that using a VPN only shifts the privacy concern from your ISP to your VPN provider.

 

[Dunuin]

Also: I'd argue that using a VPN only shifts the privacy concern from your ISP to your VPN provider.

TOR might help there a bit (unless not all nodes of the chain are surveilanced by the same party) but there you got the problem that repos are often not accessible because TOR exit nodes get blocked. For example when trying to install the ELK stack. But great that Proxmox isn't blocking TOR exit nodes yet.

 

[Machine Manager]

Hi,

please also be aware that our apt repos come signed with our GPG keys anyway, so realistically adding HTTPS on top of that does not provide much of a security benefit.

@sterzy, having HTTPS enabled would add an extra layer of security, and it would help to prevent some bugs that may arise on the signature layer. Here is one example of a past bug that allowed for attacking a repository via MITM attacks, circumventing the signature of the InRelease file: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467

 

[sterzy]

having HTTPS enabled would add an extra layer of security

I don't disagree. However, using apt over HTTP is fine. That was basically what I am trying to get across. Also, that in this scenario HTTPS is not the end-all-be-all in terms of security and provides fewer additional protections than it may seem at first.

 

[Machine Manager]

@sterzy then, changing my question: why not add the community repository to the certificate, as it could improve security in some way?
Is there any good reason to not add?

 

[fabian]

it adds overhead for (as explained in this thread) basically no gain - both resource wise (TLS is more expensive than plain, both CPU and traffic wise) and administrative (another certificate that is very important to handle).

 

[Machine Manager]

@fabian
> it adds overhead for (as explained in this thread) basically no gain
It can prevent some security issues, such as the one I had pointed: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467
Then, I think it is a considerable gain.

> both resource wise (TLS is more expensive than plain, both CPU and traffic wise)
TLS does not add that much resources overhead in today's scenario. An option could be letting plain HTTP accessible too, but IMHO, this does not make much sense.

> and administrative (another certificate that is very important to handle).
There is already a certificate deployed to that domain. However, the domain is just not in the certificate's list. Adding a domain to a certificate, especially a Let's Encrypt certificate, is an one-off action.

This certificate is already being renewed automatically by bots. It just needs this subdomain to be added to the list.

In summary, there are more reasons to add the domain to the certificate than to not add it. It would at least prevent other similar threads being opened by different people.