Hacker News Reader

Comment by FiloSottile | Hacker News Reader

It wouldn't be a conversation. The attacker would have to rely Alice's messages to Bob before switching the key. But then if the attacker let Alice (the target) receive Bob's messages they will learn theirs got delivered and the attack would fail.

So it only works once against a string of messages with no replies. That's not a conversation.

View on HN

Here's my understanding of this attack vector:

* when the client is compromised, you're screwed anyways, so let's assume the client behaves as expected.

* now, with "proper" e2e, and Alice and Bob verifying key fingerprints, their messages can't be read even if the server gets compromised.

* as it stands now with WhatsApp, AFAI understand, the server could be compromised to take Alice's message, send it on to Bob, but withhold the "delivery receipt". It could also pass back Bob's answers, and so Alice could have what appears to be a normal conversation - except that Alice only sees single ticks, instead of double blue ticks.

* then, the server could send the "hey ho, new key" message, and Alice's client would re-encrypt and re-send all messages that it thinks haven't been delivered yet, the ones with a single tick. After that, it would display the "key changed" msg to Alice (if she had set that option).

> It could also pass back Bob's answers, and so Alice could have what appears to be a normal conversation - except that Alice only sees single ticks, instead of double blue ticks.

No, it can't do this, because Bob's answers contain the "delivery receipt".

Hence, the attack doesn't work on conversations.

EDIT to reply: messages are sequential and "delivery receipts" are messages, so it would be visible if the attacker dropped some but not all messages. AFAICT.

> Bob's answers contain the "delivery receipt".

I've not seen any specific claims about the mechanism for the delivery receipt - can you link me to this?

It's not even clear to me that the delivery receipt is signed.

It's also not clear that the server must forward all the delivery receipts before it forwards the later replies.

Could it just eat them all?

EDIT: after a quick look at the spec¹, it seems that it supports out-of-order messages, meaning the server could selectively eat receipts.

[1] https://whispersystems.org/docs/specifications/doubleratchet...

So, given that, it would seem that a compromised server could pull a whole conversation (if people overlook the single tick mark), as claimed in the article?

seems like it, yes

Ah. If that is so (and it's not obvious - clearly you can get delivery or even read receipts without Bob sending an answer), then it would seem that a bad server could only intercept a long monologue, indeed, but not a conversation.

(Greetings from HS F13 :)

you get "delivered" and "read" notifications before the recipient sends you a text response, so they must be independent.

Another thing that's not clear to me: Is the receipt confirmation from Bob (used as the basis for the double-check) signed by Bob?

Reply on news.ycombinator.com