91–100 of 437 posts
Earlier quoted context omitted.
Source code can be verified. Binaries distributed via app stores may or may not have behavior different from the published code.
Certainly it's possible to remedy this situation simply by having the app author sign a checksum of binaries in the app store. Why this is not currently an option (to my knowledge) is a mystery to me.
Color me still-unconvinced. This retort does not address the fundamental point made in the Guardian piece: > “[Some] might say that this vulnerability could only be abused to snoop on ‘single’ targeted messages, not entire conversations. This is not true if you consider that the WhatsApp server can just forward messages without sending the ‘message was received by recipient’ notification (or the double tick), which u…
I think that just misconstrues how IM apps are used. You have conversations on IM apps: you send one line of text to a person, and then you don't send another until the person has at least seen the first one, if not yet responded. Otherwise you're being rude. And, presuming you are seeing reply-messages from your peer and having a back-and-forth conversation, I don't think it's actually possible for those reply-messa…
Earlier quoted context omitted.
If I understand correctly, the default is no key change notification. So for the majority of users, MITM would go unnoticed here.
I believe that you get a key change notification, but by default it doesn't require any sort of confirmation and will just continue to work with the new key.
Even if you enable the key change notification, it is "non-blocking" in WhatsApp as outlined by the blog post: when you get the key change notification, the WhatsApp client will automatically without user intervention resend undelivered messages (unlike Signal, btw, from what I understand).
Earlier quoted context omitted.
It wouldn't be a conversation. The attacker would have to rely Alice's messages to Bob before switching the key. But then if the attacker let Alice (the target) receive Bob's messages they will learn theirs got delivered and the attack would fail. So it only works once against a string of messages with no replies. That's not a conversation.
Here's my understanding of this attack vector: * when the client is compromised, you're screwed anyways, so let's assume the client behaves as expected. * now, with "proper" e2e, and Alice and Bob verifying key fingerprints, their messages can't be read even if the server gets compromised. * as it stands now with WhatsApp, AFAI understand, the server could be compromised to take Alice's message, send it on to Bob, bu…
No, it can't do this, because Bob's answers contain the "delivery receipt".
Hence, the attack doesn't work on conversations.
EDIT to reply: messages are sequential and "delivery receipts" are messages, so it would be visible if the attacker dropped some but not all messages. AFAICT.
What is the user supposed to do when they get notified of a "safety number changed" message? How do they verify they've not just been MITM? Honest question... I don't use whatsapp or signal at all.
edit: nvm, if this is man in the middle then that doesn't matter because you still exchange with each other and its not a hijack. Sorry, I made a mistake.
Earlier quoted context omitted.
To do this you must not only verify the open source code, but that the binary was built from this code, and that your operating system and every layer below it is also trustworthy. I stand by my claim that using software written by a malicious developer is game over in the vast majority of contexts.
> verify the open source code The argument here is that open source code can be verified where closed source is explicitly non-verifiable by nature. > but that the binary was built from this code Doesn't code signing address this? If not could you explain (for my own learning)? https://en.wikipedia.org/wiki/Code_signing > that your operating system and every layer below it is also trustworthy. Yep, this is the last m…
This is not a belief that people who actually do software security audits hold. Verifying binary only software is table stakes to a security audit of a third party application as you cannot trust the source provided.
Having source is a bonus for security audits not a requirement.
> That would leak information to the server about who has enabled safety number change notifications and who hasn't , effectively telling the server who it could MITM transparently and who it couldn't; something that WhatsApp considered very carefully. I am not convinced. Why should this option exist at all? Even worse, it is disabled by default. Just enable notifications for everyone and demand verification. If you…
>>[The choice to make these notifications "blocking" (i.e. to require manual verification) would] leak information to the server, etc., etc.
>Why should this option exist at all?
The option does not exist, and should not exist. That's the author's point there. You agree with him and with WhatsApp on that.
All you disagree on is implementation:
Author: "[Non-blocking defaults] provide transparent and cryptographically guaranteed confidence in the privacy of a user's communication, along with a simple user experience."
You: "Enable notifications for everyone and demand verification; if you don't want to verify, just tick "verified" without actually verifying."
How are these two substantially different? They look the same to me in terms of security and WhatsApp's implementation doesn't make you click anything.
Earlier quoted context omitted.
And it'd have to work for other platforms, too. Android is Java right? Which is even easier to RE.
Android apps can also contain native code. Indeed, WhatsApp includes such libraries, to help with Curve25519 encryption, video encoding, voice over IP, and other functionality.
There seems to be a pretty clear war going on between engineers and journalists lately. - Chris Latter [1] vs Business Insider [2] - Elon Musk vs (Bunch of outlets) - Moxie vs The Guardian I feel like journalists want to write a compelling story and engineers are on the other side like "No, those aren't facts!" I don't follow a lot of media outlets but it seems like journalists either lack the skills or don't care ab…
I don't think the Chris Lattner thing is a war at all. The journalist gave a reasonable effort to get a comment from Lattner, never got a response, so went with a story from a source they found trustworthy. Lattner issued a denial after the fact, and it's included near the top of the story. I guess it's possible that the journalist completely fabricated the story, but I think it's a lot more likely that either someon…
Oh well, can't figure out the actual facts, better just publish whatever i do have?
Seriously. Also, the "i tried to contact you" is clearly a BS defense.
It wasn't a "reasonable effort".
This is a reporter. They know that people basically never respond to interview requests during what amounts to the busiest times in their lives, and so the reporter asked just so they could say they tried.
Otherwise, they would have held the story a week or whatever until they could get a comment. Because it would be just as interesting then if it was any good.
But nope, gotta try to get it out while anyone gives a crap about the story flavor of the week because it's not substantive enough for anyone to care otherwise.