Transferring signed packages over TLS only prevents the attacker from observing which particular packages are being updated, and that’s assuming the padding alone is sufficient to obscure identification by size.

Otherwise signing packages is actually preferred, because you can do it offline, so that hacking the server is not enough to push malicious code.

Not exactly true. If you as a malicious third person can MITM the http connection for updates, you can push an older signed package with known vulnerabilities.

Only if the installer does not check/warn about downgrades.

But that assumes hardware vendors' signature verification code is correct -- and crypto is really hard to get right

Is it really that hard? Assuming you generate a public/private key, there's openssl RSA_sign and RSA_verify whose interfaces are pretty simple, clear and well documented. There's a difference between "I'm going to write a new way to do asymmetric encryption" which is really hard, and "I'm going to use RSA to verify/sign a binary" which is really easy. I'm seeing a tendency to say that crypto is hard for anything that has to do with crypto which is not the case. While erring on the side of caution is commendable, let's not push vigilance to the point where taking the hash of a file is considered hard crypto to get right.

You don't need to verify it on the target system though?

You sign at the source with a private key, and you verify on the target with the public key. The trick is only someone with the private key can create a signature that the public key can verify.

The other problem is many people wont have pre-existing copies of the required private key available. If your attacker is in a position to MitM your download of a signed binary, they're probably also in a position to MitM your retrieval of the public key. SSL/TLS certainly helps there (at least the attacker then also needs to be capable of acquiring root CA signed TLS certs for the download site and any readily available PGP key sites. It wont slow the NSA down much - but it will help against the guy with the WiFi Pineapple in your local Starbucks…)

> The other problem is many people wont have pre-existing copies of the required private key available.

We're talking about software updates, you embed the key INSIDE the software to avoid this problem.

Ahhh, good catch... Agreed.

(Though with my overly-cynical hat on, I now just suspect you've only moved the problem to the previous update's authentication - and recursively back to the initial download. How do you protect against the initial download being MitMed and having an attacker's public key inserted - this is functionally the same as HSTS - if you can MitM the first visit you win...)

You need to trust something at some point, be it TLS session and the server you’re talking with, or an SHA csum you verify with a friend (or using PGP’s WoT), and even further the process(es) and person(s) responsible for actually signing the releases.

As for “moving the problem,” it is worth it. Because it’s easier to verify the origin of the software once, then for every update. If there’s a new vulnerability in TLS this will only affect new installations. Verifying (& signing) packages offline is much more anti-fragile.

The parent explained they might not trust verification on the target system. This might not necessarily be because the target is assumed malicious, but it may only have e.g. md5sum and not sha1sum available etc. (I'm obviously no expert... the hashing examples are just examples here)

I intended to suggest you could download it on a separate system which you do trust and verify it there. Then transfer it to the target system.

He's not totally wrong. If the package is signed and the public key is trusted (the bigger 'if' actually) and the package signature passes - then it doesn't matter how it was transported. Even email is fine.

With that said, security needs to be in layers and defense in depth is critical, especially for this type of core infrastructure.

He should upgrade all infrastructure points for better security where feasible.

There's also the political reason not to use Cloudflare ... we're quickly moving to a darker Internet where traffic goes into networks like Cloudflare and nobody knows what happens inside the black box. I wonder if that's where the resistance lies.

The problem with that is that, if you as a malicious third person can MITM the http connection for updates, you can push an older signed package with known vulnerabilities.

Why isn't it? I'm sorry, I'm genuinely curious.

Over what channel do you retrieve the signature?

A signature is not a hash. As long as you know the right public key (which only needs to be transferred once), you can verify the legitimacy of the signature regardless of how it was transmitted.