special
commented
10 years ago I'll begin by addressing the concept before we discuss specific implementations. In general, I don't see many compelling benefits in using message relays as a standard practice: it reintroduces many of the problems of server-based IM and shifts trust rather than eliminating it. Trying to solve those leads into building a higher latency anonymity network on top of Tor, and that's a place I wouldn't go.
- A user's network might momentarily drop due to their ISP or VPN experiencing problems or a directed attack at them or their ISP/VPN. This is bad for anonymity as adversaries may use this to deanonymize the user.
I think it's helpful to split this attack into two variants: discovery and confirmation. Discovery would be using natural conditions (network instability, time of day) correlated with the peer's connectivity/latency to narrow down where they are, their guards, or their own connection. Confirmation is the ability to actively abuse a relay/router/clear internet target and observe the effect on your peer to validate your guesses.
Tor is naturally weak against the confirmation attack. Even in non-hidden-service usage, those attacks are very effective, especially on long-lived connections like IM. We can try to mitigate specific situations, but in many ways it's an inherent flaw of real-time communication.
I'd split the discovery attack into two categories: trusted attackers (your approved contacts) and untrusted attackers. It's most important to prevent an untrusted attacker from learning anything. Fortunately, that's something we can address with smarter treatment of hidden services and contact requests: as much as possible, I'd like to avoid exposing online state and latency to unapproved peers, at least in any useful detail.
A message relay can make it more difficult to conduct the discovery portion of this attack, but only when it completely obscures (at least within some grace period) your actual connection state. You also remain vulnerable to the same attack by (one of) your relay(s). The costs and complications are significant and the benefit is limited. A user who is very concerned about being deanonymized by their approved peers over time may be more comfortable with high-latency (email-like) services instead - where solving these problems is much more realistic.
We need more research on these topics, and how they apply to Tor and hidden services especially. There may be defenses we could use by throttling incoming circuits, introducing false latency, throttling reconnection, etc. We can't completely solve the situation, but I am certainly interested in how we can make attacks more obvious or more difficult.
2 . The user may wish to go offline for several hours (ex. school, work, sleep, etc) and still want to be able to receive messages without keeping their computer on.
This is the more compelling case for using (in some cases) message relays/servers. I'd be interested in discussing designs that would allow:
- Storage and retrieval of messages for your peers without being simultaneously online
- Without exposing, including over time, your relationships or any useful information about your communications
- With the ability to detect message loss and tampering by the server
- While maintaining the general principles and security model as they exist now
I think this could be addressed relatively simply with appropriate cryptography (Open WhisperSystems' work on asynchronous OTR is interesting) and without trusting message relay(s) with any useful information. That seems like an appropriate starting point for extending the design beyond simple peer-to-peer connections. And in the long term, with more research and understanding of the issues, it could build into helpful solutions for connectivity attacks.
What're your thoughts?
burdges
Note: This is probably beyond the scope of Torsion's design goals, but in attempt to solve some anonymity problems here is a rather long winded idea.
This topic is discussing a theoretical feature/enhancement to solve two issues:
Technical/protocol changes: A new mode OMS would require:
Scenario:
In OMS mode:
Randomly between 6-12 hours the client sends out updated info to friends on which servers to reach them on. This could be directly or perhaps though those same servers with a signed message.
Basic layout idea: Alice > Server1 > Alice > Server2 > Bob Alice > Server3 >
Message splitting, storage, and retrieval:
Cons: This method allows for the middle anonymous servers to hold encrypted message data. It is not ideal that the server can see quite a bit of info in this scenario. The server knows who sent the message, when they send it, can easily determine about how big the message is, to whom the message was sent, and when, if ever, the recipient retrieved that stored message.
Other thoughts: After 50 hours a friend's three selected Onion Messaging Servers are considered outdated and no longer a trustworthy way to reach that friend. For example, if the user is offline for 20 hours the friends client and the receiver's servers should still allow incoming messages. The server's messages could time out after 50 hours and at the time also show that the peer is no longer available. This time would ideally be randomized by at least a few hours to prevent knowing exactly when a peer went offline (ex. exactly 50 hours ago, or always at 10pm).
An alternative to using three unknown servers is using a single or few friends to store the message. This has similar problems to the three unknown servers and goes back to giving your friends potentially a lot of info about you that you might prefer they didn't have.
If one of the three servers goes offline can the other two know about it? And if so can they recreate a new third server? This seems like an security issue as if the servers could know if one when offline they must know their address, which means they might be able to collude to recreate the source encrypted message. This is not critically bad, but it is not exactly great. I2P might be able to do this by having new tunnels with new b32 addresses that cannot be linked back to a particular host, but that might also have other problems.