Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

There is no WhatsApp 'backdoor'

whispersystems.org

Post reply on HN
Print view View original

81–90 of 437 posts

Re: There is no WhatsApp 'backdoor'

#81

Post by FabHK »

FiloSottile wrote: post #61
jMyles wrote: post #5

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…

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, but withhold the "delivery receipt". 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.

* then, the server could send the "hey ho, new key" message, and Alice's client would re-encrypt and re-send all messages that it thinks haven't been delivered yet, the ones with a single tick. After that, it would display the "key changed" msg to Alice (if she had set that option).

Re: There is no WhatsApp 'backdoor'

#82

Post by gshulegaard »

UncleMeat wrote: post #63
hackuser wrote: post #56

Earlier quoted context omitted.

Open source software can be verified.

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 major piece for true security in my mind. Although there is some movement in the open hardware space as well as USB mounted OSs (http://gizmodo.com/try-the-super-secure-usb-drive-os-that-ed...).

> I stand by my claim that using software written by a malicious developer is game over in the vast majority of contexts.

Sure...perfectly accurate...but in the context you are implying that WhatsApp is malicious. To which I think "hackuser" was interpreting as "closed source is malicious" and therefore offering open source (and by implication Signal) as an alternative.

Might just be a miscommunication moment :-)

Re: There is no WhatsApp 'backdoor'

#83

Post by imranq »

na85 wrote: post #55
sebleon wrote: post #18

At the end of the day, it comes down to trusting WhatsApp. Even without a backdoor in their protocol, they can easily do all kinds of things. For instance, it could instruct specific clients to encrypt and send each message twice: one for the recipient, and one for the WhatsApp server. As long as this was off for 99.9% of users, it's unlikely that security researchers would ever detect this.

Trusting WhatsApp == trusting Facebook I can't think of a company I trust less than Facebook.

What about...Walmart, Glencore, Phillip Morris, Blackwater, Palantir...

Re: There is no WhatsApp 'backdoor'

#84

Post by jlgaddis »

throw7 wrote: post #8

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.

(Re-)verify the safety number out-of-band, like you hopefully did initially.

Re: There is no WhatsApp 'backdoor'

#85

Post by obscene »

jMyles wrote: post #69
enduser wrote: post #60

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.

That doesn't protect you against a malicious developer.

Re: There is no WhatsApp 'backdoor'

#86

Post by Groxx »

jMyles wrote: post #69
enduser wrote: post #60

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.

It kinda is - you could add it to the description.

App stores seem to be getting progressively more hostile to this kind of thing though - you can't just download an APK / iOS app, you have to do it through a device. This lets the stores do "app slimming" (and per-country / per-carrier customized apks) to remove resources you don't need (like binaries that don't match your architecture), which would change the checksum. Which is useful, but inconvenient for this goal.

Something like fdroid may be supportive of this, which would be cool. But I wouldn't expect the mainstream ones (or Apple) to ever embrace it - it'd be a bad user experience / wasted UI space in the vast majority of cases.

Re: There is no WhatsApp 'backdoor'

#87

Post by ekiru »

disiplus wrote: post #17

> The choice to make these notifications "blocking" would in some ways make things worse. 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. could not this be saved only localy ?

If resending undelivered messages to new keys waited for confirmation of the new key when safety number change notifications are enabled, then users without those notifications enabled would continue to immediately resend undelivered messages to new keys while users with the notifications enabled would not resend until the user manually OKed the change. The WhatsApp servers know (or can know) whether users have outstanding undelivered messages and can observe whether users resend them immediately after a key change. As a result, if resends after key changes waited for user confirmation with security notifications enabled, whenever a user changed keys, WhatsApp would be able to tell whether any of their contacts who had undelivered messages to that user had the notifications enabled by observing whether those contacts immediately resent the messages or not.

Re: There is no WhatsApp 'backdoor'

#88

Post by derefr »

jMyles wrote: post #5

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-messages to not implicitly also be ACKs of your own sent messages—the Axolotl ratchet underlying the protocol ensures that (I think. Crypto people chime in?)

So, yeah, you can probably get a retransmitted transcript of one person talking into a void without seeing any delivery ticks in response. You can't really get a conversation.

Re: There is no WhatsApp 'backdoor'

#89

Post by jMyles »

obscene wrote: post #85
jMyles wrote: post #69

Earlier quoted context omitted.

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.

That doesn't protect you against a malicious developer.

You mean someone publishing source code and then falsely verifying the binary checksum?

I mean, at the end of the day, it's very easy to verify - if the binary doesn't match what whomever gets when they compile, there better be a reason for it.

Regardless, I don't think this is the biggest problem facing open source.

Re: There is no WhatsApp 'backdoor'

#90

Post by tucif »

ploxiln wrote: post #74
tucif wrote: 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.

The "green padlock" was not considered enough because users would not be able to differentiate it from a big lock symbol within the page. Thus we got HSTS. (There was a time when browsers would color the entire URL bar yellow to indicate https, but that went out of favor many years ago.) Moxie deserves respect for the web vulnerabilities he discovered and raised awareness about years ago, and for his general competen…

I agree, perhaps a further version of the signal protocol could implement a definitive solution that better addresses this kind of scenario the way HSTS did for ssl certs. And combined with a friendly UI solution (like the new padlock | Secure string in chrome) would lead to easier detection of possible eavesdroppers by the lay person.
Post reply on HN