Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I am flagging this article, as the headline and first few paragraphs are very misleading, based on my understanding from: https://tobi.rocks/2016/04/whats-app-retransmission-vulnerab...

They make it sound like an intentional backdoor has been introduced to WhatsApp to facilitate monitoring.

Rather, it seems like there's a weakness in the implementation, where if a message is undelivered, an attacker could trick the sender's client into sending the undelivered message to a new key they control.

That does seem like a weakness, but not an intentional backdoor as the article initially lead me to believe. I could see how someone would trade off ease of use and message delivery with security and make that call.

Yes, it could be a subtle backdoor (with limited exploitation), and yes, open source clients would be great. But real end users use WhatsApp to encrypt their private messages on a scale never before achieved, because of the usability tradeoffs they've made. I think we should bear that in mind before describing any implementation tradeoff as a 'backdoor'.



Agree, also think it's likely this is an intentional trade off: Alice sends Bob a message but Bob's phone is broken, so he gets a new one. The message is marked as not delivered. Since Bob's old keys are lost, WhatsApp needs to generate new ones. The trade off here allows in this scenario to accept new keys transparently.

Not ideal from a security perspective but what would be the alternative? Bob meeting Alice so they can compare fingerprints? Bob sending Alice a PGP signed message?


>what would be the alternative

Alice getting a warning about key mismatch and a prompt for redelivery (or not) of the pending message. Bob-with-new-phone does not get to read Alice's messages to Bob without Alice at least having the ability to verify that Bob indeed changed phones. Yes, 99% of users will click "redeliver" without checking, but the ones for whom secrecy matters won't.

I think this is how Signal does it, and it is the only security conscious way to do it.


Yes, I personally prefer that too. But I understand if facebook decided this is too much to ask for their users.


Yeah, I've seen this behaviour with Signal. It's UI is somewhat confusing thou, it took me a while to understand that I needed to re-generate keys so what I could "fix" my conversation. There was no redelivery of the messages that couldn't be decrypted thou.


Could do it like Signal - always alert the user when a key changes, and not resend messages until the user approves it (having checked the key fingerprint via some other channel, if so inclined).

As it stands now, you have to trust both the client app on your phone, and the WhatsApp server. The idea with e2e encryption was that you only have to trust the client app on your phone.


I completely agree with you, and I am going to add that this scenario shows how difficult it is to make a one-to-one messaging system completely secure AND easy to use at the same time.


What if the originating client (Alice) was responsible for re-encrypting undelivered messages?


> They make it sound like an intentional backdoor has been introduced to WhatsApp to facilitate monitoring. Rather, it seems like there's a weakness in the implementation

If I wanted to install an intentional backdoor, I would do my best to make it look like merely a weakness in the implementation.


Therefore any time we see an implementation weakness it should be reported as an intentional backdoor? Is this really what we want?

What would we then say if we got proof that they actually put an intentional backdoor in? That's clearly a much more serious scenario (if the vendor is surreptitiously working against you, you are much more screwed than the one bug youve found), and it would be nice to be able to communicate it.

I thought that was why we had a word like 'backdoor' vs 'security bug'.


Sure, but this is now conspiracy theory logic that is impossible to disprove.


> subtle backdoor (with limited exploitation)

oh, please.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: