privacyguides/privacytools.io
Archived
1
0
Fork 0
Code Issues 304 Pull Requests 47 Activity

🌐 Website Issue | Jami is missing a warning about metadata #1357

New Issue
Open
opened 2019-09-28 08:25:43 +00:00 by Mikaela · 8 comments
Mikaela commented 2019-09-28 08:25:43 +00:00 (Migrated from github.com)
Copy Link
Copy Source

Jami (formerly Ring/SFLphone) - Gives you full control over your communications and an unmatched level of privacy. Jami has text messaging, video and audio calls, file transfer, video conferencing. [VoIP]

I am under impression that a network observer can see whom you are discussing with even while there is E2EE, but citation is needed and a warning should be added.

* https://www.privacytools.io/software/real-time-communication/ > Jami (formerly Ring/SFLphone) - Gives you full control over your communications and an unmatched level of privacy. Jami has text messaging, video and audio calls, file transfer, video conferencing. `[VoIP]` I am under impression that a network observer can see whom you are discussing with even while there is E2EE, but citation is needed and a warning should be added.
👍 1
Mikaela commented 2019-09-28 15:14:34 +00:00 (Migrated from github.com)
Copy Link
Copy Source

I cannot find a direct quote, just two parts that need someone wiser to take a look:

Ring uses OpenDHT (a distributed hash table) to connect users instead of a centralized SIP server system such as Asterisk. OpenDHT is an implementation of the same decentralized, peer-to-peer system used in BitTorrent's distributed tracker, as well as the Coral Content Distribution Network. For comparison, the founders of Skype originally worked on the Kazaa filesharing application. Skype initially utilized a derivative of the FastTrack protocol used in Kazaa, though this has changed somewhat since the program was first introduced. Additionally, components now use MSNP24, a derivative of the protocol used in the now-defunct MSN Messenger.

OpenDHT allows Ring to bypass the server-client methodology by passing along user information to each user. According to an interview on the Savoir-faire Linux blog with Guillaume Roguez, the Ring project director:

With Ring, each account is identified on the network by a personal digital footprint commonly called hash — a unique code of 40 letters and numbers linked to an identification certificate and a pair of asymmetric keys for encrypted communications. It registers itself by distributing its identity not to one but multiple equivalent servers — each machine acting in fact as an identity server for others. These machines can appear, disappear and be replaced by others at any time. The table of hashes containing all the identities of connected users and their IP addresses at a given time is distributed to all their machines.

Adrien Beraud provides further insight into the construction of Ring, noting that OpenDHT is itself not an inherently secure design; as with BitTorrent, it relies on the trust of all parties to the network to store and transmit data properly. For this reason, the encryption layer is added on top of OpenDHT, rather than trying to modify DHT to resist interference. As such, Ring utilizes PKCS asymmetric keys to ascertain the validity of the data in transit.

I guess it's implied that your Jami usage is announced wide and this leads to the concluion that someone monitoring the network can see where a connection comes from and where it's going to.

I cannot find a direct quote, just two parts that need someone wiser to take a look: > Ring uses OpenDHT (a distributed hash table) to connect users instead of a centralized SIP server system such as Asterisk. OpenDHT is an implementation of the same decentralized, peer-to-peer system used in BitTorrent's distributed tracker, as well as the Coral Content Distribution Network. For comparison, the founders of Skype originally worked on the Kazaa filesharing application. Skype initially utilized a derivative of the FastTrack protocol used in Kazaa, though this has changed somewhat since the program was first introduced. Additionally, components now use MSNP24, a derivative of the protocol used in the now-defunct MSN Messenger. > > OpenDHT allows Ring to bypass the server-client methodology by passing along user information to each user. According to an interview on the Savoir-faire Linux blog with Guillaume Roguez, the Ring project director: > >> With Ring, each account is identified on the network by a personal digital footprint commonly called hash — a unique code of 40 letters and numbers linked to an identification certificate and a pair of asymmetric keys for encrypted communications. It registers itself by distributing its identity not to one but multiple equivalent servers — each machine acting in fact as an identity server for others. These machines can appear, disappear and be replaced by others at any time. The table of hashes containing all the identities of connected users and their IP addresses at a given time is distributed to all their machines. > > Adrien Beraud provides further insight into the construction of Ring, noting that OpenDHT is itself not an inherently secure design; as with BitTorrent, it relies on the trust of all parties to the network to store and transmit data properly. For this reason, the encryption layer is added on top of OpenDHT, rather than trying to modify DHT to resist interference. As such, Ring utilizes PKCS asymmetric keys to ascertain the validity of the data in transit. * https://www.techrepublic.com/article/privacy-focused-skype-alternative-ring-shows-promise/ * https://git.jami.net/savoirfairelinux/ring-project/wikis/technical/Protocol#contacting-another-account I guess it's implied that your Jami usage is announced wide and this leads to the concluion that someone monitoring the network can see where a connection comes from and where it's going to.
Mikaela commented 2019-09-28 15:17:49 +00:00 (Migrated from github.com)
Copy Link
Copy Source

See also:

See also: * https://git.jami.net/savoirfairelinux/ring-project/issues/495 - Stream Isolation + Tor * https://git.jami.net/savoirfairelinux/ring-project/issues/501 - I2P * https://git.jami.net/savoirfairelinux/ring-project/issues/509 - Privacy issues of linking pictures and videos from third party sources * https://git.jami.net/savoirfairelinux/ring-project/issues/622 - Tor * https://git.jami.net/savoirfairelinux/ring-project/issues/630 - I2P
lrq3000 commented 2020-02-20 15:41:21 +00:00 (Migrated from github.com)
Copy Link
Copy Source

From this link you posted above, they say the ICE offering (ie, the message sent to the OpenDHT network to signal that the client is listening for incoming calls) is hashed: SHA1("callto"+deviceID). So if you have the target deviceID you want to call, you can compute the SHA1 and initiate the call, but otherwise an external observer will only get the SHA1 hash and not directly the deviceID.

From [this link](https://git.jami.net/savoirfairelinux/ring-project/wikis/technical/Protocol#contacting-another-account) you posted above, they say the ICE offering (ie, the message sent to the OpenDHT network to signal that the client is listening for incoming calls) is hashed: `SHA1("callto"+deviceID)`. So if you have the target deviceID you want to call, you can compute the SHA1 and initiate the call, but otherwise an external observer will only get the SHA1 hash and not directly the deviceID.
blacklight447 commented 2020-03-02 12:09:52 +00:00 (Migrated from github.com)
Copy Link
Copy Source

From this link you posted above, they say the ICE offering (ie, the message sent to the OpenDHT network to signal that the client is listening for incoming calls) is hashed: SHA1("callto"+deviceID). So if you have the target deviceID you want to call, you can compute the SHA1 and initiate the call, but otherwise an external observer will only get the SHA1 hash and not directly the deviceID.

wouldn't it be possible for the observer of the openDHT to calculate the same hash valua and correlate it?

> > > From [this link](https://git.jami.net/savoirfairelinux/ring-project/wikis/technical/Protocol#contacting-another-account) you posted above, they say the ICE offering (ie, the message sent to the OpenDHT network to signal that the client is listening for incoming calls) is hashed: `SHA1("callto"+deviceID)`. So if you have the target deviceID you want to call, you can compute the SHA1 and initiate the call, but otherwise an external observer will only get the SHA1 hash and not directly the deviceID. wouldn't it be possible for the observer of the openDHT to calculate the same hash valua and correlate it?
lrq3000 commented 2020-03-03 13:11:59 +00:00 (Migrated from github.com)
Copy Link
Copy Source

Yes but since the deviceID is randomly generated, it's akin to cracking a password from its SHA1 hash, it can take a very very long time. I think the deviceID is never directly exposed on the OpenDHT, but it would be better to ask directly the devs for confirmation, as, if I understand correctly, @aberaud seemed to write that is the case since at least 2016 (in the predecessor Ring), with the caveat that IP addresses were still exposed (I don't know if this changed?):

Ring developer here. Ring is a distributed communication platform, its nodes are part of a DHT network, so their IP are indeed exposed.

That's a downside of using a distributed network: DHT nodes IP addresses are exposed on the distributed network, which is a valid privacy concern. The current design doesn't allow to cryptographically link DHT nodes with Ring public keys and we work to make this separation as strong as possible.

Yes but since the deviceID is randomly generated, it's akin to cracking a password from its SHA1 hash, it can take a very very long time. I think the deviceID is never directly exposed on the OpenDHT, but it would be better to ask directly the devs for confirmation, as, if I understand correctly, @aberaud seemed to write that is the case since at least 2016 (in the predecessor Ring), with the caveat that IP addresses were still exposed (I don't know if this changed?): >> Ring developer here. Ring is a distributed communication platform, its nodes are part of a DHT network, so their IP are indeed exposed. > > That's a downside of using a distributed network: DHT nodes IP addresses are exposed on the distributed network, which is a valid privacy concern. The current design doesn't allow to cryptographically link DHT nodes with Ring public keys and we work to make this separation as strong as possible.
aberaud commented 2020-03-03 17:01:09 +00:00 (Migrated from github.com)
Copy Link
Copy Source

I am under impression that a network observer can see whom you are discussing with even while there is E2EE, but citation is needed and a warning should be added.

Since we establish peer-to-peer connexions between contacts, network operators could see the p2p TCP channel and infer who you're talking to. I guess this is true for most IP communication systems (even centralized) as network operators could infer source/destination IPs from the traffic flow, unless a specific strategy is deployed to hide the source/destination IP (like Tor). Currently the media channel is UDP-only which doesn't work over Tor but that might change (however the real-time communication experience might not be great by going over Tor).

Yes but since the deviceID is randomly generated, it's akin to cracking a password from its SHA1 hash, it can take a very very long time. I think the deviceID is never directly exposed on the OpenDHT, but it would be better to ask directly the devs for confirmation, as, if I understand correctly, @aberaud seemed to write that is the case since at least 2016 (in the predecessor Ring), with the caveat that IP addresses were still exposed (I don't know if this changed?):

Device and account public keys are published on the DHT. This is used for the user lookup and multi-device feature. Knowing the device ID or public key doesn't allow to know who's calling who, however a network observer could infer some meta-data.

> I am under impression that a network observer can see whom you are discussing with even while there is E2EE, but citation is needed and a warning should be added. Since we establish peer-to-peer connexions between contacts, network operators could see the p2p TCP channel and infer who you're talking to. I guess this is true for most IP communication systems (even centralized) as network operators could infer source/destination IPs from the traffic flow, unless a specific strategy is deployed to hide the source/destination IP (like Tor). Currently the media channel is UDP-only which doesn't work over Tor but that might change (however the real-time communication experience might not be great by going over Tor). > Yes but since the deviceID is randomly generated, it's akin to cracking a password from its SHA1 hash, it can take a very very long time. I think the deviceID is never directly exposed on the OpenDHT, but it would be better to ask directly the devs for confirmation, as, if I understand correctly, @aberaud seemed to write that is the case since at least 2016 (in the predecessor Ring), with the caveat that IP addresses were still exposed (I don't know if this changed?): Device and account public keys are published on the DHT. This is used for the user lookup and multi-device feature. Knowing the device ID or public key doesn't allow to know who's calling who, however a network observer could infer some meta-data.
👍 3
lrq3000 commented 2020-03-03 17:49:30 +00:00 (Migrated from github.com)
Copy Link
Copy Source

Thank you very much @aberaud for taking the time to clarify this issue!

Thank you very much @aberaud for taking the time to clarify this issue!
lrq3000 commented 2021-06-02 02:24:11 +00:00 (Migrated from github.com)
Copy Link
Copy Source

PR #2293 addresses this issue for all P2P networks, they all share the same issue of non anonymity of senders and receivers.

(PS: Given the discussion above, it doesn't appear that Jami leaks any more metadata than any other secure P2P network, it's normal that the nodes IDs are propagated through the network via a DHT for a distributed P2P system.)

PR #2293 addresses this issue for all P2P networks, they all share the same issue of non anonymity of senders and receivers. (PS: Given the discussion above, it doesn't appear that Jami leaks any more metadata than any other secure P2P network, it's normal that the nodes IDs are propagated through the network via a DHT for a distributed P2P system.)
This repo is archived. You cannot comment on issues.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
:mag:🤖 Search Engines
approved
approved, waiting for a PR
 dependencies
Pull requests that update a dependency file
 duplicate
feedback wanted
high priority
I2P
The Invisible Internet Project (I2P)
 iOS
low priority
OS
Operating Systems
 Self-contained networks
Social media
stale
A label for stalebot if it gets added
 streaming
Anything related to media streaming.
 todo
Tor
Anything covering the Tor network
 WIP
active work in progress, do not merge or PR (yet)!
 wontfix
Issues or bugs that will not be fixed and/or do not have significant impact on the project.
 XMPP
Extensible Messaging and Presence Protocol
 [m]
Matrix protocol
 ₿ cryptocurrency
ℹ️ help wanted
↔️ file sharing
⚙️ web extensions
Browser Extension related issues
 ✨ enhancement
❌ software removal
💬 discussion
🤖 Android
🐛 bug
💢 conflicting
📝 correction
Correction of content on the website
 🆘 critical
📧 email
🔒 file encryption
📁 file storage
🦊 Firefox
Firefox & forks, about:config etc.
 💻 hardware
🌐 hosting
🏠 housekeeping
Anything primarily related to site cleanup.
 🔐 password managers
🧰 productivity tools
🔎 research required
🌐 Social News Aggregators
🆕 software suggestion
👥 team chat
🔒 VPN
Virtual Private Network
 🌐 website issue
*Technical* issues with the website.
 🚫 Windows
👁️ browsers
🖊️ digital notebooks
🗄️ DNS
Domain Name System
 🗨️ instant messaging (im)
🇦🇶 translations
Anything covering a translated version of the site
No labels high priority ℹ️ help wanted 🐛 bug 📝 correction 🔎 research required 🗨️ instant messaging (im)
Milestone
No items
No Milestone
Assignees
Clear assignees
jonah
No Assignees
1 Participants
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: privacyguides/privacytools.io#1357