Add an optional "Manual Synchronization" mode to mitigate against end-to-end confirmation attacks by powerful adversaries #712

New Issue

beginnings · 2023-08-27T19:30:53Z

beginnings commented

2023-08-27 19:30:53 +00:00

Context and threat model:

In the context of the Tor network, if an adversary can control or observe the nodes where traffic is entering and leaving the network, they can correlate traffic and confirm that a user connected to a particular destination. Such end-to-end confirmation attacks (also called end-to-end correlation attacks) have been studied and demonstrated as successful by researchers. See for example this 2015 paper on the topic.

A real-world example of such an attack has been given by the FBI in 2012 in the investigation against anarchist hacker Jeremy Hammond. Investigators suspected Hammond of being the person behind an anonymous Internet Relay Chat (IRC) alias. Since they knew Hammond's home address, investigators were able to monitor network traffic outside his home, and correlate the traffic with online presence of the IRC alias, despite Hammond's use of Tor. This correlation was later used as corroborating evidence in his trial. For more information on this case, see this article.

I would argue that real-time messaging applications are particularly susceptible to end-to-end confirmation attacks because of the ability of an adversary, once they know their target's handle on the messaging platform, to trigger incoming network traffic on the target's side by sending them messages on the platform (when the target is online).

For example, consider the following scenario: a human rights organization operates anonymously in a country where they are the target of State repression. They decide to start using Cwtch as a communication platform. Because they need to reach out to people as largely as possible, they make their Cwtch handle public on the web. The local State wants to know who is behind the organization, and they already have a few suspects in mind, so they start monitoring the suspects' home networks. They wait until the organization's Cwtch handle goes online, send a few messages to it, and correlate the timing of the sent messages with incoming network traffic on the suspects' home networks. After enough messages to eliminate false positives, they know which of the suspects is operating the organization's Cwtch handle.

One possible mitigation against such attacks described in the 2015 paper linked above is the generation of "dummy traffic": if a target's home network continuously generates dummy incoming and outgoing Tor traffic (or "padding"), end-to-end confirmation attacks are harder to achieve. We can hope that such a mitigation gets implemented in software some day, but it seems out-of-scope for Cwtch.

Proposal:

However, one thing that Cwtch could put in place to mitigate against such attacks is an optional "Manual Synchronization" mode. This opt-in mode would be activated in the app settings. When activated, a new "Synchronize" button appears in a prominent place in the app. The app then stops all network connections, and only connects to the network briefly when the "Synchronize" button is pressed (or when the user opts-out of the mode). The user can type messages as they normally would, but they will only be sent (and others' messages will only be received) when the "Synchronize" button is pressed. Of course, this would work best when using Cwtch servers, and may require message queuing and hybrid group functionality. With the mode activated, an adversary can no longer trigger incoming network traffic on the user's side, thus making end-to-end confirmation attacks way more difficult to achieve.

**Context and threat model:** In the context of the Tor network, if an adversary can control or observe the nodes where traffic is entering and leaving the network, they can correlate traffic and confirm that a user connected to a particular destination. Such end-to-end confirmation attacks (also called end-to-end correlation attacks) have been studied and demonstrated as successful by researchers. See for example [this 2015 paper](https://ntnuopen.ntnu.no/ntnu-xmlui/bitstream/handle/11250/296084/KMuller_2015.pdf) on the topic. A real-world example of such an attack has been given by the FBI in 2012 in the investigation against anarchist hacker Jeremy Hammond. Investigators suspected Hammond of being the person behind an anonymous Internet Relay Chat (IRC) alias. Since they knew Hammond's home address, investigators were able to monitor network traffic outside his home, and correlate the traffic with online presence of the IRC alias, despite Hammond's use of Tor. This correlation was later used as corroborating evidence in his trial. For more information on this case, see [this article](https://medium.com/beyond-install-tor-signal/case-file-jeremy-hammond-514facc780b8). I would argue that real-time messaging applications are particularly susceptible to end-to-end confirmation attacks because of the ability of an adversary, once they know their target's handle on the messaging platform, to trigger incoming network traffic on the target's side by sending them messages on the platform (when the target is online). For example, consider the following scenario: a human rights organization operates anonymously in a country where they are the target of State repression. They decide to start using Cwtch as a communication platform. Because they need to reach out to people as largely as possible, they make their Cwtch handle public on the web. The local State wants to know who is behind the organization, and they already have a few suspects in mind, so they start monitoring the suspects' home networks. They wait until the organization's Cwtch handle goes online, send a few messages to it, and correlate the timing of the sent messages with incoming network traffic on the suspects' home networks. After enough messages to eliminate false positives, they know which of the suspects is operating the organization's Cwtch handle. One possible mitigation against such attacks described in the 2015 paper linked above is the generation of "dummy traffic": if a target's home network continuously generates dummy incoming and outgoing Tor traffic (or "padding"), end-to-end confirmation attacks are harder to achieve. We can hope that such a mitigation gets implemented in software some day, but it seems out-of-scope for Cwtch. **Proposal:** However, one thing that Cwtch could put in place to mitigate against such attacks is an optional "Manual Synchronization" mode. This opt-in mode would be activated in the app settings. When activated, a new "Synchronize" button appears in a prominent place in the app. The app then stops all network connections, and only connects to the network briefly when the "Synchronize" button is pressed (or when the user opts-out of the mode). The user can type messages as they normally would, but they will only be sent (and others' messages will only be received) when the "Synchronize" button is pressed. Of course, this would work best when using Cwtch servers, and may require [message queuing](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues/414) and [hybrid group](https://git.openprivacy.ca/cwtch.im/cwtch-ui/wiki/One-Pager:-Managed-Groups-%28-A-Roadmap-towards-Hybrid-Groups%29) functionality. With the mode activated, an adversary can no longer trigger incoming network traffic on the user's side, thus making end-to-end confirmation attacks way more difficult to achieve.

beginnings commented

2023-09-17 15:01:50 +00:00

Noting here that the "Start offline" feature mentioned in #92 could mostly solve this issue?

If users are able to start Cwtch offline, and then while using it briefly go online then back offline, it would mostly achieve the same thing as the "Manual synchronization" mode I suggest above - except in two clicks instead of one?

Noting here that the "Start offline" feature mentioned in https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues/92 could mostly solve this issue? If users are able to start Cwtch offline, and then while using it briefly go online then back offline, it would mostly achieve the same thing as the "Manual synchronization" mode I suggest above - except in two clicks instead of one?

domelike commented

2023-11-08 20:34:49 +00:00

There is a SimpleX issue that discusses mitigations to the same threat. It describes a "manual sync button" as is talked about above, but also has this second proposal which might also be relevant to Cwtch as well, with a better UX:

Perhaps it could have two options: to only sync when you ask it to explicitly, or to regularly sync at a random interval within a user-submitted time range (for example, a randomized value between 5 and 60 seconds).

The current implementation of "Offline mode" allows a Cwtch user to selectively connect only to specific groups, which is a good start. However, this issue is still relevant because it by default will stay connected to the group, versus the idea of a 'manual sync button' that briefly connects just for a single sync (a longer connection is just as vulnerable to correlation by any untrusted parties in the groups).

There is a [SimpleX issue](https://github.com/simplex-chat/simplex-chat/issues/3197) that discusses mitigations to the same threat. It describes a "manual sync button" as is talked about above, but also has this second proposal which might also be relevant to Cwtch as well, with a better UX: >Perhaps it could have two options: to only sync when you ask it to explicitly, or to regularly sync at a random interval within a user-submitted time range (for example, a randomized value between 5 and 60 seconds). The current implementation of "Offline mode" allows a Cwtch user to selectively connect only to specific groups, which is a good start. However, this issue is still relevant because it by default will stay connected to the group, versus the idea of a 'manual sync button' that briefly connects just for a single sync (a longer connection is just as vulnerable to correlation by any untrusted parties in the groups).

Sign in to join this conversation.