Live data from Hacker News

There is no WhatsApp 'backdoor'

whispersystems.org

101–110 of 437 posts

Re: There is no WhatsApp 'backdoor'

#101
post #92
post #88

Earlier quoted context omitted.

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…

I think that, much of the time, in a journalistic setting, apps like WhatsApp are used to report. If WhatsApp is used to report conditions at an event of political upheaval in a totalitarian state - and the receiver isn't routinely and quickly replying, this is a damn serious problem.

WhatsApp seems to be built for a threat model where a single message (and you can think of a block of messages without reply as semantically equivalent to a single message, here) being compromised is no big deal; only a conversation being compromised is a problem.

If there are cases (like this) where a single-message compromise is a big deal, and WhatsApp cares about these cases, then the simplest solution would be for WhatsApp to add a preference in the client to switch on—as the article describes—a "blocking mode" for re-key notifications, where retransmissions aren't allowed by default.

Re: There is no WhatsApp 'backdoor'

#103
post #81

Earlier quoted context omitted.

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…

> It could also pass back Bob's answers, and so Alice could have what appears to be a normal conversation - except that Alice only sees single ticks, instead of double blue ticks. 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…

> Bob's answers contain the "delivery receipt".

I've not seen any specific claims about the mechanism for the delivery receipt - can you link me to this?

It's not even clear to me that the delivery receipt is signed.

Re: There is no WhatsApp 'backdoor'

#105
post #81

Earlier quoted context omitted.

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…

> It could also pass back Bob's answers, and so Alice could have what appears to be a normal conversation - except that Alice only sees single ticks, instead of double blue ticks. 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…

Ah. If that is so (and it's not obvious - clearly you can get delivery or even read receipts without Bob sending an answer), then it would seem that a bad server could only intercept a long monologue, indeed, but not a conversation.

(Greetings from HS F13 :)

Re: There is no WhatsApp 'backdoor'

#106
post #101
post #92

Earlier quoted context omitted.

I think that, much of the time, in a journalistic setting, apps like WhatsApp are used to report. If WhatsApp is used to report conditions at an event of political upheaval in a totalitarian state - and the receiver isn't routinely and quickly replying, this is a damn serious problem.

WhatsApp seems to be built for a threat model where a single message (and you can think of a block of messages without reply as semantically equivalent to a single message, here) being compromised is no big deal; only a conversation being compromised is a problem. If there are cases (like this) where a single-message compromise is a big deal, and WhatsApp cares about these cases, then the simplest solution would be f…

And - as the article describes - such a blocking mode would immediately expose to WhatsApp which users had not enabled it, and who would therefore be safe(er) to MITM (because they probably don't verify key changes in any meaningful way).

Re: There is no WhatsApp 'backdoor'

#107
post #59
post #22

Earlier quoted context omitted.

He does address this: Once the sending client displays a "double check mark," it can no longer be asked to re-send that message. That means a user is able to verify visually that the end-to-end is working. "users might not notice" doesn't seem to me as a strong argument to state this as a backdoor. This would imply not noticing that you don't have a green padlock on chrome is a backdoor too, and it clearly is not.

A little. Without reading the Guardian piece, I wouldn't even guess that delivery notifications have anything in common with security properties. In other words, the messages are secure only when there is a double checkmark, not just a single checkmark. How am I supposed to know that?!? I am not even sure what do the checkmarks mean. Frankly, that's not a "backdoor", that's just a poorly thought out GUI (in my opinio…

Absolutely. There is no evident connection that can be done from the double checkmark to a "secured communication".

But when you think about it, the double check is a read confirmation so if we are in an end-to-end encrypted scenario, and the message content was read, it means the recipient's device was able to decrypt it successfully.

This tells you that the recipient is still using the same set of keys that your device thought it had and used to encrypt the message.

Re: There is no WhatsApp 'backdoor'

#108
post #60

Earlier quoted context omitted.

Open source software can be verified.

Source code can be verified. Binaries distributed via app stores may or may not have behavior different from the published code.

You can build and check against the binaries. What's your point?

Re: There is no WhatsApp 'backdoor'

#109
post #9

>The WhatsApp clients have been carefully designed so that they will not re-encrypt messages that have already been delivered. Once the sending client displays a "double check mark," it can no longer be asked to re-send that message. This prevents anyone who compromises the server from being able to selectively target previously delivered messages for re-encryption. Can this be verified? Can this be verified to be th…

If your threat model includes using a malicious app to send messages then you lose anyway. Nothing can ever be done to send messages securely using whatsapp if the client is neither trusted nor verified. This is true for basically all software that you use.

This is true for basically all proprietary software that you use. FTFY

Re: There is no WhatsApp 'backdoor'

#110
post #71
post #9

>The WhatsApp clients have been carefully designed so that they will not re-encrypt messages that have already been delivered. Once the sending client displays a "double check mark," it can no longer be asked to re-send that message. This prevents anyone who compromises the server from being able to selectively target previously delivered messages for re-encryption. Can this be verified? Can this be verified to be th…

Isn't it possible (in fact trivial) to sniff the traffic generated by WhatsApp and verify that it is indeed the message transmitted, encrypted by the key on the device? Has anyone performed such an audit?

This might be possible, but I don't think it addresses the issue that such an exploit could be turned on and off remotely. The only way to be sure would be to do such sniffing all the time.
Post reply on HN