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
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 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.
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 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.
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.