Users online/offline status can be tracked by 3rd parties that are not contacts

morganava commented 3 years ago

The Problem

So the problem here is that if an attacker knows your ricochet ID, they can determine if you are online by attempting to connect to the onion service. This type of metadata can be used to correlate one's real-life activity with your online identity (as with Ross Ulbricht's IRC activity: https://arstechnica.com/tech-policy/2015/01/silk-road-trial-federal-agent-explains-how-he-trapped-ulbricht/ ).

When a user launches Ricochet-Refresh, they launch their onion service and then also attempt to connect to all of the onion services of the users in their contact list. If a contact does not appear online, the client will periodically attempt to reconnect. Because we always launch the onion service, any tor client that knows the user's ricochet id can just attempt to connect If the socket connection is made, then they can determine that the user is online.

This problem is fundamentally not fixable (without centralized servers mediating/authenticating connections) due to how onion services work. There is no way to hide the fact that an onion service exists and is online if a malicious 3rd party knows the onion address.

This means that handing out your ricochet id publicly is effectively handing over the ability to determine when you online status to strangers.

Better Documentation/Communication

We need to a good page of documentation that non-technical users can understand so that they can fully understand the risks of using Ricochet-Refresh. Users need to understand the risks associated with giving somebody their ricochet id. Ideally this is a (localized) one-pager with easy to understand diagrams

Partial Technical Solution

A 'hidden' mode could be implemented where the user skips launching their onion service, and only attempt outgoing connections. This way, you could still talk to your friends without strangers being able to connect to you and gather metadata about when you are online.

We could further enhance this by only connecting to contacts you initiate chat with (so you only appear to come online when you initiate a chat).

The problem here is if two users both wish to be hidden but also chat. As neither user would have an onion service running, neither would be able to initiate conversation. One of them must effectively announce to anyone listening that they are online.

Brainstorming

Maybe we could get around this 'always on' problem by providing 'trusted' contacts with a secret per-user onion service that is always enabled when Ricochet-Refresh is running, and only use the ricochet id as a sort of introduction point. Unlike v2, v3 onion services are not discoverable (bar brute forcing onion addresses of course), so adversaries would not be able to follow your online status (unless your trusted contacts become compromised).

This sort of scheme could effectively give users control over when other users can add them as contacts, while also appearing online to trusted contacts.

I don't know just spitballing here.

morganava commented 3 years ago

From #tor-dev discussions:

Sebastian: pospeselr: in any case, I think this will create a much bigger burden on the network than currently, depending on the amount of users.
Sebastian: As long as most people have only a hand full of contacts it's no big deal
Sebastian: But if Signal did it it would be insane
pospeselr: hah
Sebastian: because you need a quadratic amount of descriptor storage/connections/etc
pospeselr: mmhm
pospeselr: well sort of
pospeselr: i mean yes
pospeselr: it's N*M where is total users and M is average number of contacts
pospeselr: worst case everyone is everyone's friend
Sebastian: "please use this software only if you have no friends"
Sebastian: :)
pospeselr: haha
Sebastian: the amount of connections is also much increased, because any connected clients keeps these connections open to the tor network even when their contacts are offline
Sebastian: which right now they do not
pospeselr: for all of your onion services
Sebastian: which may not matter much if everyone is online always
pospeselr: is there much overhead for maintaining an onion service connection?
pospeselr: or is it literally just periodic 'keep alive' packets
Sebastian: There isn't that much overhead, except you keep a circuit open, so the relays have to permanently allocate memory for you
Sebastian: and when the circuit breaks you need to re-establish it
pospeselr: ahh right the relays
Sebastian: I really only care about the relays here
Sebastian: clients can easily sustain it
Sebastian: I guess I don't have a good v3 resource estimation
Sebastian: would be interesting

m-simonelli commented 3 years ago

RE network strain - could we re-use these "ephemeral" onion services for multiple contacts in some non-deterministic manner?

yanmaani commented 3 years ago

Would client auth do the trick here? That would allow you to get away with two onion services:

Public onion service, handle contact requests, can be shut down if you want to
Private onion service, handle messages, 1 (revokable) key for each contact

From my understanding, client auth is DoS resistant and doesn't have any costs for the network.

morganava commented 1 year ago

@yanmaani client auth does not fix anything for us here w/ regards to cyberstalking, as the tor daemon will notify the connecting client if an onion service requires onion auth (via custom SOCKS5 error codes).

For further discussion see: https://gitlab.torproject.org/tpo/core/torspec/-/issues/119

AyrA commented 10 months ago

I guess to solve this problem you need to provide a ricochet service application. People that don't want their ricochet online activity seen could run the service on a server somewhere 24/7, and use the ricochet client to connect to it. All network relevant operations would happen on the service, and the ricochet client only acts as a UI. This kills any form of passive online checks. The only way to detect if the user is online is to perform an active probe and send an actual contact request to the client, but there's no guaranteed way to find out whether the user is offline or just busy or ignoring you.

This type of service also gives you the benefit that people can send you messages while you're offline.

odiferousmint commented 2 weeks ago

provide a ricochet service application

What do you mean by that? How would this work with the security in mind if you provide a Ricochet service application? The goal should be to avoid that altogether. We should not rely on third party services for anything to begin with. Correct me if I am wrong. The less we rely on (be it third-psrty services, APIs, what have you), the better.

AyrA commented 2 weeks ago

The service can be run locally (and most likely will for most people). But if you want to prevent others from figuring out if you're online you must maintain an alive TOR descriptor at all times. These descriptors have a somewhat short lifetime however.

By splitting the UI from the backend, the backend can be written in a way so it can be run as a Windows service or Linux daemon process. Most users probably wouldn't use this feature and have the UI start and stop its own instance in the same way that the Tor Browser starts and stops its Tor instance. But privacy minded people can run the service on an always-on server to make it impossible to figure out whether they're offline or just ignoring you.

This architecture provides other benefits

Easy to write your own UI without potentially touching or misusing cryptographic routines
Your contacts can always send you messages and you don't depend on both using Ricochet at the same time for message delivery because the backend is always online to send and receive (provided the backend is run as service executable)
Cryptographic keys can be confined to the service and don't ever need to enter the UI
Protocol elements can be exposed in a high level (JSON) format that doesn't requires protocol knowledge for encoding and decoding in the UI. In other words, even large protocol changes have no impact on the UI. For example, the switch from onion v2 to v3 would have been much easier.
Enables integration with other applications. For example someone could write an SMTP/IMAP/POP3 adapter on top of it to make it E-mail like or an XMPP adapter to integrate it with other chat software
Some new features can be implemented without needing a protocol change. An identity could for example be configured as a chat room simply by making it relay all inbound messages to all contacts.
Service can be used for automated messaging. For example a bot that acts like a search engine and provides results for your messages.
The service can update independently of the UI, for example when a new Tor client is released.

morganava commented 2 weeks ago

FWIW already planning on having a clean separation between the chat and the UI. Indeed, as part of the V2 -> V3 transition we split the layers and all of the chat/tor stuff lives in its own static lib with a clean C-FFI (though there is still a lot of Qt in the non-UI layer):

https://github.com/blueprint-freespeech/ricochet-refresh/blob/main/src/libtego/include/tego/tego.h

V4 will definitely follow this track and make a possible implementation of what you've described possible.

blueprint-freespeech / ricochet-refresh