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

241–250 of 437 posts

Re: There is no WhatsApp 'backdoor'

#241

Post by theveloped »

As with all end-to-end encryption it stops at the "end". It is this unencrypted state, in which humans consume data, that can't be defended by crypto.

Therefore the only way to be completely safe, is to make sure both you and your conversation partner don't decrypt their message until it's on an offline device only you have access to.

But end-to-end encryption where the interface (mobile app/phone) is controlled by the parties you want to protect your data from is not possible. WhatsApp could send freaking screenshots back of the unencrypted data if they wanted. For nearly all other threat models whatsApp's encryption is a wonderful add-on.

Re: There is no WhatsApp 'backdoor'

#242

Post by taneq »

moxie wrote: post #237
rndgermandude wrote: post #220

Earlier quoted context omitted.

> The notification that you see in WhatsApp, Signal, SSH, PGP, or whatever is the defense. That defense, which happens to be the only defense, is turned off by default in WhatsApp. You seem to argue they do so because it's bad UX to present such notification by default. That's - in my humble opinion - like suggesting browsers should turn off TLS chain errors by default because it's bad UX and just proceed with the co…

> That defense, which happens to be the only defense, is turned off by default in WhatsApp. > You seem to argue they do so because it's bad UX to present such notification by default. That's - in my humble opinion - like suggesting browsers should turn off TLS chain errors by default because it's bad UX and just proceed with the connection as if nothing happened... One thing we've learned over the years is that secur…

Why are unsigned key changes a 'normal' thing? It'd be trivial to sign the new public key with the old private key, maintaining a chain of trust.

Re: There is no WhatsApp 'backdoor'

#243

Post by disiplus »

ekiru wrote: post #178
disiplus wrote: post #152

Earlier quoted context omitted.

thats then a timing attack, but the client could replace the mesaage with a placeholder and send that immidietly, and the real message after the user approves. this way server could not know.

I think that could mostly work. The placeholder message would have to be of identical length to the original and the resent message would have to use later sequence numbers/message ids (or whatever is used to identify individual messages) so the server couldn't tell that the placeholders were placeholders. One issue is that it would mean that, in the case of an active attack where the server substituted a key they kn…

to find out if the user has notification on would be the same as doing the attack, and to find that for all users is the same as mitm all users.

im not sure how is the security of those who dont have notifications on worse in this case then what they have now.

if i want to i should be able to say if somebody changes the key i want to first verify the key before i send the message to that person.

lets say you organise a big protest vs some regime. i know who you are and i know that you comunicate with the number xyz. i redirect that number to my. in the meantime you send me a list of names that are in our group and adresses. i reconect with a xyz number and get the list and everything. even if youbget the notification its to late.

Re: There is no WhatsApp 'backdoor'

#244

Post by Veratyr »

moxie wrote: post #237
rndgermandude wrote: post #220

Earlier quoted context omitted.

> The notification that you see in WhatsApp, Signal, SSH, PGP, or whatever is the defense. That defense, which happens to be the only defense, is turned off by default in WhatsApp. You seem to argue they do so because it's bad UX to present such notification by default. That's - in my humble opinion - like suggesting browsers should turn off TLS chain errors by default because it's bad UX and just proceed with the co…

> That defense, which happens to be the only defense, is turned off by default in WhatsApp. > You seem to argue they do so because it's bad UX to present such notification by default. That's - in my humble opinion - like suggesting browsers should turn off TLS chain errors by default because it's bad UX and just proceed with the connection as if nothing happened... One thing we've learned over the years is that secur…

> Key changes in a messenger are totally different. They happen under normal conditions

This doesn't have to be the case. If you stop coupling a key to a device and instead couple a key to a person (generating a key deterministically from a password for example), they can be changed far more rarely.

Re: There is no WhatsApp 'backdoor'

#245

Post by garrettr_ »

true_religion wrote: post #235
rndgermandude wrote: post #220

Earlier quoted context omitted.

> The notification that you see in WhatsApp, Signal, SSH, PGP, or whatever is the defense. That defense, which happens to be the only defense, is turned off by default in WhatsApp. You seem to argue they do so because it's bad UX to present such notification by default. That's - in my humble opinion - like suggesting browsers should turn off TLS chain errors by default because it's bad UX and just proceed with the co…

Do browsers tell you about certificate reissues by default?

No, but they don't have to because (the vast majority of) users don't establish trust in website's TLS certificates themselves; instead, they use a trusted third party: the set of all trusted certificate authorities in their browser or operating system's root store. End-to-end encrypted messengers like Signal and WhatsApp don't rely on a trusted third party to establish trust, instead (rightly) leaving it up to users to establish trust between each other.

Re: There is no WhatsApp 'backdoor'

#246

Post by jMyles »

moxie wrote: post #207
rndgermandude wrote: post #170

Earlier quoted context omitted.

This allows WhatsApp to MITM. Whatapps can rekey both Alice and Bob, decrypt both their messages from that point onwards (incl unsent messages) and forward them re-encrypted with their real keys. The only notification might be that rekeying warning, if the users have turned it on. In this scenario even the double-checkmarks are present. This is contrary to WhatsApp's claim that even they cannot snoop. PS: I just chec…

> This allows WhatsApp to MITM. Whatapps can rekey both Alice and Bob, decrypt both their messages from that point onwards (incl unsent messages) and forward them re-encrypted with their real keys. The only notification might be that rekeying warning, if the users have turned it on. In this scenario even the double-checkmarks are present. This is contrary to WhatsApp's claim that even they cannot snoop. You've just d…

Moxie,

I think it's fair to say that you are the world thought leader on these matters right now.

One thing that the rest of us are wondering right now is:

> I've been impressed with the level of care that WhatsApp has given to that requirement.

To what degree do you really know that? Is there a place where we can read about your interactions with Facebook, the level of access they've given you, and the degree to which they have allowed your recommendations to shape the contours of their implementation?

Nothing less than the strength of dissent lies in the balance of questions like these.

> I think we should all remain open to ideas about how we can improve this UX within the limits a mass market product has to operate within, but that's very different from labeling this a "backdoor."

I agree that the jump to scary terminology is dangerous.

However, at the end of the day, I think that many of us have been trying to make a simple point that shows that there is a sort of crossing of that line:

WhatsApp claimed that they were simply unable to intercept communications, and now we find out that, without any user interaction or approval, messages which haven't received the "double check" are re-transmitted when a new key is generated.

In some highly specific but easy-to-imagine scenarios (eg, a journalist on the ground in Tahrir Square using WhatsApp to report on conditions, receiving no replies), WhatsApp is hugely vulnerable in a way that most of us didn't think it was.

So look: nobody here is trying to diminish your tireless work and your accomplishments in bringing freedom into the information age.

But there are nuances here that are important, and fleshing them out is a big part of what this community is about.

Re: There is no WhatsApp 'backdoor'

#248

Post by inconclusive »

moxie wrote: post #207
rndgermandude wrote: post #170

Earlier quoted context omitted.

This allows WhatsApp to MITM. Whatapps can rekey both Alice and Bob, decrypt both their messages from that point onwards (incl unsent messages) and forward them re-encrypted with their real keys. The only notification might be that rekeying warning, if the users have turned it on. In this scenario even the double-checkmarks are present. This is contrary to WhatsApp's claim that even they cannot snoop. PS: I just chec…

> This allows WhatsApp to MITM. Whatapps can rekey both Alice and Bob, decrypt both their messages from that point onwards (incl unsent messages) and forward them re-encrypted with their real keys. The only notification might be that rekeying warning, if the users have turned it on. In this scenario even the double-checkmarks are present. This is contrary to WhatsApp's claim that even they cannot snoop. You've just d…

> the majority of users will probably not verify keys. That is our reality

The server having knowledge of who it can MITM without getting caught is irrelevant if nearly 100% of users verify keys.

I want a better reality.

Re: There is no WhatsApp 'backdoor'

#249

Post by nl »

jMyles wrote: post #234
tptacek wrote: post #140

Earlier quoted context omitted.

That's identically true of open-source software. To put it in the theoretical terms you're probably most comfortable with: the programming language used to represent a computer program has nothing fundamentally to do with whether it can be verified. Obviously some languages are easier to verify programs in than others, but the gap between assembly and C in ordinary compiled programs is surprisingly small. Open vs. cl…

tptacek, Over the years interacting with you here on HN, I think this basically sums up the worldview that puts you and I at odds: > Open vs. closed-source software is a concern orthogonal to verifiability. Is there a place where you have written at length, defending this assertion? I am open to it. But it does not resonate with my understanding, nor my (substantial, I think) experience in deployments of open- and cl…

What do you mean by verifiablity?

If you are using a casual, inspection = verification definition then I think most would agree that it is true that open source is easier to inspect.

But "verified" software often means formal mathematical verification, and that is orthogonal to if the source is open.

Re: There is no WhatsApp 'backdoor'

#250

Post by smartbit »

taneq wrote: post #242
moxie wrote: post #237

Earlier quoted context omitted.

> That defense, which happens to be the only defense, is turned off by default in WhatsApp. > You seem to argue they do so because it's bad UX to present such notification by default. That's - in my humble opinion - like suggesting browsers should turn off TLS chain errors by default because it's bad UX and just proceed with the connection as if nothing happened... One thing we've learned over the years is that secur…

Why are unsigned key changes a 'normal' thing? It'd be trivial to sign the new public key with the old private key, maintaining a chain of trust.

> It'd be trivial to sign the new public key with the old private key

How would these 'trivial' steps look like if a telephone gets stolen or upgraded? What easy steps did Facebook & Moxie overlook?

Post reply on HN