3 ms·
they arent miss-use resistant when it comes to mitm attacks
by tcfhgj 3y ago
they arent miss-use resistant when it comes to mitm attacks
- woodruffw 3y agoNeither Signal nor WhatsApp is MITM-able. Could you explain why you think they are? (Signal and WhatsApp also have forward secrecy properties that PGP, as an ecosystem, is nowhere close to providing. PGP very much still operates under the "one master key that you must never ever lose or disclose" paradigm.)
- matheusmoreira 3y agoThey are trivially MITM-able. Not long ago there was news posted here that telecom employees are selling SIM swaps. There's your MITM vulnerability. People can pay to impersonate others by taking over their phone numbers and consequently their messenger accounts. This attack will be noticeable: there will be a message warning the user that the cryptographic keys have changed on the other end. You know what else generates these warnings? Reinstalling WhatsApp, switching phones... They're basically noise to users by now due to alarm fatigue. How many users even know what that this key stuff means anyway? How many people even use the built-in key verification function which consists of just scanning a QR code? I've yet to meet a single person who cares about any of this stuff.
- deleted 3y ago[deleted]
- sowbug 3y agoMy guess is that the term "MITM" is being overfit to include the basic problem of verifying that A's identity really belongs to A rather than M.
- 7bit 3y agoBut you can verify the other end. Not wanting so so that ist Not a Problem of the App or protocol.
- 01HNNWZ0MV43FF 3y agoIt's hard to prove the whole chain of possibly-tampered hardware and proprietary software hasn't gotten any malicious update to steal private keys at any point
- woodruffw 3y agoIf your threat actor is omnipotent, you’re going to have a very hard time designing a coherent threat model against them. Neither Signal nor PGP nor hiding under the bedsheets will protect you from an adversary capable of directly recording your screen. (But note: absent something like that, it in fact is possible for Signal to prove that you’re communicating with the same identity you initiated with. That’s the whole point of authenticated key agreement, which is not something that PGP can natively perform.)
- 01HNNWZ0MV43FF 3y ago"communicating with the same identity you initiated with." Is that not tofu, which is easy in many crypto systems?
- hpk42 3y agoSignal acts as a central key server and can present different identity keys to users, so signal itself can middle communications unless there is out-of-band verification of identity keys. This is described here https://www.ndss-symposium.org/wp-content/uploads/2017/09/09-when-signal-hits-the-fan-on-the-usability-and-security-of-state-of-the-art-secure-mobile-messaging.pdf https://www.ndss-symposium.org/wp-content/uploads/2017/09/09... (II. Background) and many other places.
- woodruffw 3y agoThis is conflating TOFU and (active) MITM. If you don’t check your peer’s security number in Signal, you are essentially trusting the key directory to be honest about its identity mapping. This is identical to trusting a PGP keyserver, except that Signal has empirically developed a more secure and private key directory than the PGP keyserver ecosystem. In other words: you always need to perform OOB identity verification, regardless of your messaging system of choice. There is no way around this; it’s a fundamentally social and UX problem rather than a cryptographic one. But this doesn’t change the fact that, once you have a trusted identity, Signal’s MITM protections are significantly stronger than PGP’s (including forward secrecy, as noted before).
- remram 3y ago> In other words: you always need to perform OOB identity verification Web-of-trust alleviates that, to some extent.
- woodruffw 3y agoThe WoT has been defunct in PGP for over 4 years at this point[1]. It was also never a particularly good solution to this problem, because it (1) was itself largely unauthenticated and blindly trusted by relying parties, much like a normal key directory, and (2) failed to encode what key holding parties were trusted for (the classic example being that I absolutely trust party A to do C for me, but this does not imply that I want to encourage networked party B to trust A for D). And of course the keyserver birthday attacks and DoS, as cherries on top :-) (I think WoTs can solve these problems. But PGP's implementation has been so far the most ambitious tried by a semi-large audience, and it didn't hold up. We need a better starting point.) [1]: https://inversegravity.net/2019/web-of-trust-dead/ https://inversegravity.net/2019/web-of-trust-dead/