Show better error (or none at all) when we receive a replayed message

[TarkanY]

• I have searched open and closed issues for duplicates

---

Bug description

In my master thesis I did a security check of the Signal protocol. Among other things, I executed replay attacks on an active Signal session with the help of a tool called Fiddler. I have found a problematic case and would like to suggest enhancements (see attachment): „I found that the error message in the Signal app is potentially misleading when a replay attack occurs.“

Steps to reproduce

• Install Telerik Fiddler
• write a message from Alice to Bob
• sniff at the same time with Fiddler
• use the composer function in fiddler while sniffing, which give you the possibility to replay a former sending message
• open your signal chrome extension
• you will get an error, called "BAD MAC", but no one knows, that this could a hacking attempt

Actual result: Like I mentioned above, there is just a hint of BAD MAC (see attachment)
Expected result: The result could be to update the source code and to have a look at the Telegram UI. The screenshot shows how it works on Telegram. Compared to the Telegram Chrome Extension I am missing some settings:
Set additional password
Active Sessions
Email-Login

My suggestion (especially for the Chrome Extension) is that the user is informed of hacking attempts. Instead of an internal error like “Bad MAC”, the user should be informed about the following things:

Active Sessions:
IP Address
Location
Platform
Device

Screenshots

Platform info

Operating System: Microsoft Windows 7
Browser: Google Chrome Version 58.0.3029.110 (64-

Signal version: Chrome Extension Version: 0.41.0 or below)

Link to debug log

[liliakai]

1. The fact that you got a bad mac error is a bug. The intended behavior in the event of a duplicate message is that it is silently dropped, because...

2. There are some scenarios where the server might deliver the same message to a device more than once. If you do see a replay, it is far far more likely to be caused by the server than by a hacker. Adding some kind of "hacking" warning in this situation is just going to cause unwarranted alarm.

If you want to help solve 1. then it would be most helpful to extend the test suite to reproduce it.

[TarkanY]

Hi lilikai,

I thought a bit bout your answer (I know it is a bit time gap:):

It couldn´t be just a bug. I think it should be the right answer from the server. I replayed my own https request. In fact of that, it should tell the receiver that there was a bad mac. Bad Mac makes sense, because that´s what a digest like MAC is for. To check things like integrity. My question was more like, why the sender in that case myself, do not get a hint or some thing like that. Why it couldn´t be a real MITM attack. And you know it´s easy to see the traffic in an open WIFI system like cafe etc. Eve could easily try to use Alice´s captured traffic to try to hack or to listen to that conversation between Alice and Bob.

Could you please explain a bit more detailed, what you mean with extending the test suite ?

Thank you!

[ideologysec]

Hi Tarkan,

I think you're missing the point as far as 1) goes. Because you're not successfully sending a new message, but instead replaying an already sent message (which will never be displayed, and can't be used to phish or attack a user), the server should handle this the same way it handles all duplicate messages - by silently dropping them. If you replay a message and the receiver never receives the (spoofed) second copy, what harm is done? There's nothing a user can do about a Bad MAC error, whether internally or externally caused, so the server should handle that silently (and the fact that it does not is the bug that lilikai was referencing - no popups should be seen in the case of duplicate messages, regardless of cause).

As far as signing out of sessions goes, signing out of a session isn't going to fix a replay "attack" problem - far better to just silently fail to deliver the second replayed message.

Test suite: there is a CI test suite for Signal Desktop that is used to test builds before distribution. The suggestion was to write more tests for that suite to test for situations like these so that it can be verified that replayed messages are handled correctly (silently dropped instead of Bad MAC errors).