Not in the strict sense if it's state-mandated MITM (you are forced to install a specific root certificate to legally connect to the internet).

But also in the other case, not all is lost: Not every malware can (or even tries to) defend itself against any antivirus software in existence. The machine might be compromised, but being able to retrieve the correct upadate for the hypothetically unaffected malware scanner can still give you the signal that your machine is infected and you should reinstall it.

The signature would use asymmetric encryption, so unless the attacker had access to the signing key, it would be impossible for the attacker to sign a modified version of the payload.

EDIT: I see what you mean. radicaldreamer stated that a malicious root certificate is installed, but signature validation wont help there. But, it will help when downloading from mirrors or HTTP.

You verify against the signature that's in the current version. Now this may mean that you need to do stepped upgrades to versions that are cross signed to get new certificates. That or you have at least one https update method that gets a signing cert for the application.

Can’t you switch out the signatures inflight, too?

Yes. But IIRC there have been attacks on Debian package fetching anyways.

This has to do with circularity. If you are building a TLS library that needs to fetch OCSP Responses dynamically, you might not have an easy time using HTTPS to do it. Well, obviously you'd have to disable the use of OCSP for validating the OCSP Responder's TLS server certificate, but still you have a re-entrance requirement, and anyways the OCSP Responses are signed. (Or, well, you could use OCSP to validate an OCSP Responder's TLS certificate if you had code to detect a circular dependency, then stop and consider it validated. This would allow the use of OCSP for validating OCSP Responder TLS server certs where ultimately you could use HTTP for a non-privacy-sensitive certificate or where you could elide OCSP Responder TLS server cert validation but still use HTTPS to fetch OCSP Responses so as to provide confidentiality about the server names you're visiting.)

The main reason to want to use HTTPS for fetching OCSP Responses has to do with privacy rather than security relative to active attacks.

It's probably time to revisit this.

All analogies are flawed but this feels a bit more like the tamper proof labels on products, the antivirus company threw some chicken in a produce bag, and called it good.

At this point a lot of antivirus software is just useless or actively harmful.

> I understand HTTPS is industry best practice

Right. Unlike your McDonalds example, there is already an industry standard solution to this problem. The software ""engineers"" who neglected to implement it should be found criminally negligent for the harm they caused to their users. I know this is an unpopular suggestion on HN because code monkeys want all the glory of the "engineer" job title without any of the responsibility.