According to the article however, the notification is given after the messages are resent. There is nothing the user can seemingly do to prevent retransmission on a forced key change. This prevents further information from being sent, but in case of undelivered messages, they could be snooped on.

Sure, this could certainly leak some information, but it's hard to argue that this is a "backdoor".

A way of exploiting it is talked about in the article which would effectively allow Facebook/Whatsapp, or whoever is coercing them, to read all messages sent by a particular device.

It makes WhatsApp effectively not E2E encrypted. All messages can be recovered by Facebook. How is that NOT a backdoor?

No, all messages cannot be recovered by Facebook. Read the article - messages that are not yet delivered can potentially be read; if it has been delivered it cannot be retrieved.

You go read the article. The deciding factor is not whether the message has been delivered, but whether WhatsApp servers report to the device that the message has been delivered. There's nothing stopping them from claiming that no messages have been delivered and thus recovering all messages (as long as they had been preselected for false delivery reports) despite true delivery status.

> but whether WhatsApp servers report to the device that the message has been delivered

It is hard to check what WhatsApp does, but in Signal it is not the server, but a recipient who sends delivery receipt. WhatsApp then has to either recognize encrypted receipts or allow only one-way conversation during attack. Carrying out the whole attack just to decrypt "hi, are you here?" is not really interesting.

The delivery receipt is the message that is directly sent after the message has been delivered. Not too hard to distinguish those from other text messages.

So they can recover the messages, right? However, wouldn't these messages still be encrypted? Sure, they force a key change, and the messages are encrypted using the new key and sent. Theoretically, an attacker could have multiple copies of the same message, but these messages would still be encrypted under a variety of different keys right? Wouldn't the content of the messages still be secure?

Unless the key-change forces the user to be using an insecure key-pair, but is that actually happening?

New encryption (public) key is selected by the attacker, so he knows the decryption (private) key. Basically attacker just puts real device offline and registers his own device.

Wouldn't the attacker need to be authenticated as the user of the real device for this to work?

All messages, sent while a person is offline. It is bad, but not nearly as bad as "all messages"

It is in fact all messages. They can simply not deliver the first message and force a resend record that mesaage. Afterwards force again a resend with the old encryption key and deliver that mesaage. No one would get a notification.

I can see how you would leave the receiver in the dark by sending them the original, deferred message, but how would asking the sender's device to resend with a different key not result in a notification?

Furthermore, as soon as the sender attempts to deliver another message to the recipient, they would get another notification (because the encryption key changed back to the real key); alternatively the attacker could continue blocking (and reading) messages to the recipient, but the lack of delivery would be noticeable.

You could escalate it into a MITM rather easily, though, by attacking both ends; but again, a key change notification should be displayed to both parties.

Assuming the closed sourced app works as advertised, obviously.

Yes, you are right. But I think most people did not enable the security option so they wouldn't detect any interception of messages.

Well, what you are describing is a regular MITM attack. Unless you validate fingerprints, this is a risk with _all_ public key-based protocols.

Can't they (WhatsApp) simulate a user being offline?

I happened to have the Security Notifications on for a while now. I see the message: "X's security code has changed." pretty often. Under what circumstances does a new pair of encryption keys get generated?

One circumstance is when you put your sim card in a different phone. The new phone recognises that you already have a WhatsApp account, as it's tied to your phone number, but it doesn't have your private key, so it will generate a new pair and start exchanging the public part.

Maybe the very fact that you want to be notified of key change events got you marked as suspicious ;-)

I think when people swap sims in their device it triggers a key change

A new pair of keys are also generated when a device is wiped and restored from backup (in my experience on iOS).

I don't think this is as serious as it seems, this exploit only applies to undelivered messages, which granted is not great, but is at least something.

And any WhatsApp update could potentially include code to snoop on decrypted messages so exploits that can only be performed from the WhatsApp server side - i.e the example in the article about snooping entire conversations - are not really that relevant.

Having said that, it's disappointing and they should adopt Signal's approach.

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.

> "it's not something a general attacker can do but it would enable WhatsApp/Facebook to read conversations"

So it downgrades "end-to-end encryption" to "transport layer security".