Did you miss this from the article?

> Boelter said: “[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 users might not notice. Using the retransmission vulnerability, the WhatsApp server can then later get a transcript of the whole conversation, not just a single message.”

In other words, what seems like "a vulnerability that only affects some messages" could be turned into a full blown interception capability with very little change.

It is just as easy to have the clients send a copy of all generated keys to a central server for storage, no need to bother with this re-transmission subterfuge at all.

What you are seeing is not some vast conspiracy, it is a compromise made by some back-end engineer to get a front-end product manager off their ass without anyone thinking through a better UI option.

"So if a user loses their phone you are telling me that all unread messages are lost forever?"

"Yes."

"That won't work. Users will complain, someone will have to deal with those complaints, this just won't work."

"Ok, maybe we just push the unread messages back to the sender's phone and automatically re-send when the recipient gets a new phone."

"Sure, that works. So, about this other problem..."

In retrospect, it is fairly obvious that the send needs some control over re-transmission, but if you have never been a situation like this it is only because no one uses your code.

If a user loses their phone, I think they have a lot more to worry about than a few missed WhatsApp messages anyway. I don't think this is a "common sense" compromise that WhatsApp made here, especially in the context of them promising end-to-end encryption.

It's kind of like that other nonsense tech companies are doing these days, by supporting U2F auth, but then requiring you also set-up SMS auth in parallel, so that "if you lose your U2F key you can go back in with the SMS"

Yeah, except that completely eliminates the point of using a U2F key in the first place, since your security would be no better than when you're just using SMS auth.

Or we can go back to "security questions", which I think most agree now are just not worth it, despite the fact that they can help users "recover their passwords".

If end-to-end encrypted messages can be intercepted through this, then WhatsApp shouldn't be offering this feature. The downside is much greater than the upside.

If I lose my phone, I expect my new phone to have proper continuity on the messages. I'd rather have that than any encryption, to be honest. I don't care if the government spies on me. I do care if something someone sent me gets lost.

Then don't use a messenger that promises end-to-end encryption. Client side encryption is all about ensuring only clients that hold private keys can read messages delivered to them.

More like, you can stop using this messenger because, guess what? It does what I want and not what you want. You move.

You should at least have a backup of your private key so you can import it on your new phone rather than having the sender re-encrypt to whatever key your new phone decides to generate.

It's possible for any message that is not marked as delivered.

All Facebook has to do is not mark messages as delivered, i.e. lieing to the device, which can probably be done easily. So they could ask a device to regenerate keys and send the same message again, over and over again.

This would just result in the same encrypted message being sent over and over, albeit encrypted with different keys each time, right? The only way the content of the message would be vulnerable is if one of the new keys are insecure/compromised, unless there's something I'm missing.

I suspect that, i think server has ability to request any individual message to be transmitted with new key.

As I mentioned in my comment, any exploit that can only be performed by the server is essentially irrelevant as we already can't have perfect trust in the server.

edit: I'll respond to everyone as I worded this poorly. What I mean is that an attack that can only be performed by Facebook/WhatsApp(depending on if you believe they are kept separate) is mostly irrelevant as they could always push an update to the App/Play Store that sent all the decrypted messages to their servers anyway and we'd be none the wiser as it's all closed source. So why would they choose to use the vulnerability when this is fair simpler and could access far more messages with the update?

I'll concede that it's worrying if their server somehow became compromised but I'm seeing that as being highly unlikely.

I thought that was the whole point of end-to-end. That you don't need trust in the server because the messages are opaque. If this is an exploit that can be performed by a compromised server, it's very much relevant

So, just to clarify my understanding:

Basically, what we have here is a weakness in the client, namely a provision that allows the server to send the client a fresh key and ask for re-encryption and re-sending with the new key. This, in turn, would allow for a good old MITM attack if the server were to be compromised.

This re-encryption and re-sending of messages would be without intervention by the user, though a message "new key" would be displayed to the user provided they had chosen the option to display such notifications (which are disabled by default).

What's unclear to me is whether only messages that have not yet been delivered would be affected, or all.

> if the server were to be compromised.

IMO they have been since they joined Facebook.

If you're serious about security, every computer outside your control should be considered compromised, regardless of what you think about the owning company.

With Signal, I have an E2E connection where if I trust both clients, I can trust the connection. WhatsApp, however, has client code that will essentially reveal any unsent messages to the server on request. And then you just have to trust this compromised computer with any message you send.

Aren't all messages undelivered, until they are?

Hehe, yes, but the point is this:

if you had verified fingerprints with Bob and are happily chatting with him, all the messages that reached him (two tick marks in WhatsApp) are safe.

Only those that have not yet been delivered (one tick mark) would, when the server sends you you a new key, be re-encrypted and re-sent.

All of this, as usual, is predicated on the client behaving as promised.

From the news article:

Boelter said: “[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 users might not notice. Using the retransmission vulnerability, the WhatsApp server can then later get a transcript of the whole conversation, not just a single message.”

I frankly didn't understand what was said here.

I guess what they're suggesting is to compromise the server in such a way that it does not send "delivered" receipts for any messages anymore (even though it actually delivers them to Bob, and Bob answers, and a "normal" conversation ensues).

Then, at some point later, Eve on the compromised server could send a "oops, here's a new key, send everything undelivered again" message. Then, the client, as it is now, would just re-encrypt and re-send all those messages it deems undelivered so far (and then pop up the "key changed" message, if you had requested it in the settings).

You'd recognise the attack by seeing only single ticks on messages, even if Bob had seen them and answered.

The next question would be can the server mark a message as undelivered after it's already marked it as delivered.

If it can un-deliver all messages as well as have them re-sent with a new key then there may as well be no keys.

Is the server sending the client a new key to use? Or is the server telling the client to generate a new key?

We can't have perfect trust in the server, so this feature being supported by the client breaks the security guarantees of WhatsApp's E2E encryption.

Nicely put.