11 ms·
http or https doesn't matter (in fact, you shouldn't rely on it because the end user could be MITM'd already with a root certificate maliciously installed on th
by radicaldreamer 3y ago
http or https doesn't matter (in fact, you shouldn't rely on it because the end user could be MITM'd already with a root certificate maliciously installed on their device).
You should sign binaries and verify and consider the network/distribution method compromised by default.
- dixie_land 3y agoIf the user is MITM'd, what's preventing the attacker also replace the signature to verify against?
- kuhsaft 3y agoThe 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.
- pixl97 3y agoYou 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.
- littlestymaar 3y agoAnd how do you ensure the integrity of “the signature that's in the current version”? Because live patching the signature in a program to force verification of an invalid payload is exactly how many software/game cracks work.
- pixl97 3y agoI mean, if you can't verify the integrity of the application you're already running then it's already game over. You're talking about downloading another executable and running it to life patch which is the exact opposite of what I'd suggest. The currently running (trusted) executable downloads and verifies the signature of the binary. Then after verification you execute it. If your trusted binary is validating invalid data then you've already messed up somewhere.
- littlestymaar 3y agoRe-read the thread, because you're misunderstanding the threat model here. The starting point was: an attacker has control over the system so that “the end user could be MITM'd already with a root certificate maliciously installed on their device”. In that case, there's nothing “trusted” on your machine anymore and all bets are off. Doing signature verification in app instead of relying on HTTPS is security theater[1]. [1] or it could be “defense in depth” but that's an argument I'd only accept from someone who really understands what they're talking about, and only in a context where everything else being being done properly. Most of the time “defense in depth” is just an argument for the security theater.
- kuhsaft 3y ago> the end user could be MITM'd already with a root certificate maliciously installed on their device If a malicious root certificate is installed, then the user’s system is already compromised and signature validation won’t help.
- TonyTrapp 3y agoNot 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.