not necessarily--in terms of hashes, i was referring to the practice of serving hashes via TLS and larger binaries via http. i believe virtualbox does this, for example. in such cases as long as you trust the TLS connection used to obtain the hashes, you can reasonably trust the binary obtained insecurely as much as you trust your TLS connection and your hashing algorithm. and indeed, hashes could/should be replaced with signatures in those circumstances, and sometimes are (e.g. tor project, but they also serve tor browser binaries via tls).
most people most of the time trust signatures/hashes served over TLS. in cases where they don't trust the upstream CA (which is commonly influenced/chosen by the developers), there's also a good chance they shouldn't rationally trust the source of that code. i see your point technically, but in practice you're almost describing a "trusting trust" attack, which i don't think is the most common threat model for app downloads.
and i agree re: signed executables, but we live in a TOFU world and vanishingly few people personally verify fingerprints OOB with devs, so for many people not looking at trust paths and such, you're practically talking about trusting EFF's CA vs. mozilla's. perhaps that's a significant distinction to some, but i'd probably characterize it differently than you have.
Comments
not necessarily--in terms of hashes, i was referring to the practice of serving hashes via TLS and larger binaries via http. i believe virtualbox does this, for example. in such cases as long as you trust the TLS connection used to obtain the hashes, you can reasonably trust the binary obtained insecurely as much as you trust your TLS connection and your hashing algorithm. and indeed, hashes could/should be replaced with signatures in those circumstances, and sometimes are (e.g. tor project, but they also serve tor browser binaries via tls).
most people most of the time trust signatures/hashes served over TLS. in cases where they don't trust the upstream CA (which is commonly influenced/chosen by the developers), there's also a good chance they shouldn't rationally trust the source of that code. i see your point technically, but in practice you're almost describing a "trusting trust" attack, which i don't think is the most common threat model for app downloads.
and i agree re: signed executables, but we live in a TOFU world and vanishingly few people personally verify fingerprints OOB with devs, so for many people not looking at trust paths and such, you're practically talking about trusting EFF's CA vs. mozilla's. perhaps that's a significant distinction to some, but i'd probably characterize it differently than you have.