When starting the client on multiple devices with the same private key and therefore the same hidden service,
inconsistencies were found. A client C communicating with multiple receivers A, B has no indication that multiple
endpoints are listening. Messages sent from C would sometimes end up at both receivers A, B and sometimes
5at either A or B. We suspect that this is in correlation with the protocol design, where every message needs an
acknowledgement. A compromised private key could be abused by a malicious actor with client B to read communication
between A, C without visible notification. We experienced visual indications on client A during testing but believe this can
be circumvented by a specially built ricochet client.
From IRC discussion that explains above observations:
pospeselr: suppose I generate keys for a v3 onion service
pospeselr: and then i launch tor and tell it to start up said onion service on multiple machines
pospeselr: effectively having multiple hosts for a single onion service
pospeselr: what's supposed to happen there?
Sebastian: the one which uploaded its descriptor last would get chosen
Sebastian: it's a bit non-deterministic due to randomness of latency and which relay your client chooses to fetch the descriptors from
pospeselr: is there any way for the original onion service to know it has been booted?
Sebastian: different relays might have different descriptors cached for your service
Sebastian: connect to itself
Sebastian: well, not connect, but fetch the descriptor
A client could try to connect to its own onion service before starting its own onion service. A client receiving a connection from itself could terminate on receiving a message from itself.
When starting the client on multiple devices with the same private key and therefore the same hidden service, inconsistencies were found. A client C communicating with multiple receivers A, B has no indication that multiple endpoints are listening. Messages sent from C would sometimes end up at both receivers A, B and sometimes 5at either A or B. We suspect that this is in correlation with the protocol design, where every message needs an acknowledgement. A compromised private key could be abused by a malicious actor with client B to read communication between A, C without visible notification. We experienced visual indications on client A during testing but believe this can be circumvented by a specially built ricochet client.
From IRC discussion that explains above observations: