Ring: Free software for distributed and secured communication(ring.cx)
ring.cx
Ring: Free software for distributed and secured communication
http://ring.cx/en
56 comments
I think this is their code:
GNOME client: https://github.com/max3903/SFLphone
KDE client: https://github.com/Elv13/sflphone-kde
Sounds like they recently relocated from their old homepage at http://sflphone.org to this new domain and just don't have everything in order yet.
GNOME client: https://github.com/max3903/SFLphone
KDE client: https://github.com/Elv13/sflphone-kde
Sounds like they recently relocated from their old homepage at http://sflphone.org to this new domain and just don't have everything in order yet.
Their wiki:
https://projects.savoirfairelinux.com/projects/ring/wiki
According to this their code repos:
Daemon:
https://gerrit-ring.savoirfairelinux.com/ring-daemon
Client library:
git://anongit.kde.org/libringclient
Clients:
https://gerrit-ring.savoirfairelinux.com/ring-client-gnome
git://anongit.kde.org/ring-kde
https://gerrit-ring.savoirfairelinux.com/ring-client-macosx
Not really well organized.
https://projects.savoirfairelinux.com/projects/ring/wiki
According to this their code repos:
Daemon:
https://gerrit-ring.savoirfairelinux.com/ring-daemon
Client library:
git://anongit.kde.org/libringclient
Clients:
https://gerrit-ring.savoirfairelinux.com/ring-client-gnome
git://anongit.kde.org/ring-kde
https://gerrit-ring.savoirfairelinux.com/ring-client-macosx
Not really well organized.
Ring-KDE announcment:
https://elv13.wordpress.com/2015/05/07/announcing-ring-a-dis...
(I am one of the developer, ask me anything)
EDIT: There is screenshots on that page
(I am one of the developer, ask me anything)
EDIT: There is screenshots on that page
> The ZRTP encryption mechanism is no longer supported (please use TLS+SRTP)
I thought SRTP used certificates rather than the diffie-hellman handshake used by ZRTP -or to put it another way, doesn't this destroy forward secrecy?
I thought SRTP used certificates rather than the diffie-hellman handshake used by ZRTP -or to put it another way, doesn't this destroy forward secrecy?
ZRTP may be back at some point. We had to disable it because of dependency issues (we switched to LibAV from CCRTP due to a long string of stability problems and constant regressions, not what you want for a network facing library). While you are right that this open the door to MiM attacks, this can be mitigated by certificate pinning and should be mostly fixed once we switch to a closed network (see some comments below). As it is implemented now, it all depend on how you transmit the Ring hash. This hash is the public key id, so if, for example, you double click on a Google contact with a Ring "phone number", the problem doesn't exist. So, all in all, a mix of trusted hash distribution, certificate pining and chain of trust should eliminate the problem from all angles. Again, this is work in progress (remember, this is an alpha) and ZRTP may come back if we get the resources/contribution to implement it in LibAV.
Thank you for the detailed reply.
Can I confirm that without ZRTP, or rather, with the current implementation, there's no forward secrecy; so should the keys get compromised either through technological or legal attack, all bets are off?
Can I confirm that without ZRTP, or rather, with the current implementation, there's no forward secrecy; so should the keys get compromised either through technological or legal attack, all bets are off?
Well, if you lose your private key and it get into their hand, as of now, yes, you can be impersonalized. As for perfect forward secrecy, it will be enabled sooner or later.
We currently don't handle the case where your computer itself get compromised and the disk content is made available. Those scenario should be handled by encrypting your devices and sandboxing network facing applications. In Linux, we also use DBus as the main IPC between the client and the daemon. Anyone with root access could theoretically mess with it and do a local MiM attack. There is little any application can do about this kind of compromission so it is kind of pointless to try to tackle them. At best it would slow such an attack, at worst give a false sense of security.
We currently don't handle the case where your computer itself get compromised and the disk content is made available. Those scenario should be handled by encrypting your devices and sandboxing network facing applications. In Linux, we also use DBus as the main IPC between the client and the daemon. Anyone with root access could theoretically mess with it and do a local MiM attack. There is little any application can do about this kind of compromission so it is kind of pointless to try to tackle them. At best it would slow such an attack, at worst give a false sense of security.
As I asked in my direct comment on this submission:
What are the advantages compared to Tox?
I see one advantage of Tox compared to Jitsi. Account management is decentralized on Tox and federated on the protocols Jitsi supports.
Are there plans to support Tox as a backend?
What are the advantages compared to Tox?
I see one advantage of Tox compared to Jitsi. Account management is decentralized on Tox and federated on the protocols Jitsi supports.
Are there plans to support Tox as a backend?
As of now we have no plan to support Tox. We initially evaluated this and decided against. Ring is based on open standards such as SIP (rfc3261), TLSv1.2 (rfc5246), SRTP (rfc3711), vCards (rfc6350) and many more.
We are also inter-operable with existing SIP infrastructure such as corporate phone system and classical phone provider with optional SIP accounts. We will continue to be as standard compliant as we can rather than create/support yet another custom communication protocol. What Ring bring to this existing mesh of technologies is the ability to connect people using a decentralized peer-to-peer network.
We are also inter-operable with existing SIP infrastructure such as corporate phone system and classical phone provider with optional SIP accounts. We will continue to be as standard compliant as we can rather than create/support yet another custom communication protocol. What Ring bring to this existing mesh of technologies is the ability to connect people using a decentralized peer-to-peer network.
Support for non-obsolete and secure standardized protocols seems to me to be a good thing.
However, I see a difference between the protocols you've given and Tox: Tox is not standardized.
So, why creating your own protocol instead of using Tox for this?
As of now we have no plan to support Tox. We initially evaluated
this and decided against.
Ring is based on open standards (...).
However, I see a difference between the protocols you've given and Tox: Tox is not standardized.
What Ring bring to this existing mesh of technologies is the
ability to connect people using a decentralized peer-to-peer network.
So, why creating your own protocol instead of using Tox for this?
> This technology for peer-to-peer discovery is also not standardized, I assume.
DHT has been used in the wild for more than a decade now, it is very well understood. SIP over DHT idea has also been studied[1] academically for a long period of time, even if it was never really implemented in commercial products. Finally, our P2P "protocol" is still using the standards mentioned above for cryptographic identity and other negotiation details, so there is very little that isn't fully standard.
[1] Example: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.183... (not used for the current Ring implementation)
DHT has been used in the wild for more than a decade now, it is very well understood. SIP over DHT idea has also been studied[1] academically for a long period of time, even if it was never really implemented in commercial products. Finally, our P2P "protocol" is still using the standards mentioned above for cryptographic identity and other negotiation details, so there is very little that isn't fully standard.
[1] Example: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.183... (not used for the current Ring implementation)
DHT has been used in the wild for more than a decade now,
it is very well understood.
Does Ring support communication without having to register any type of account on any third-party server?
[1]: https://jenkins.libtoxcore.so/job/Technical_Report/lastSucce...
No server account are required, it is what DHT is for. However, if you do have a server SIP account, we also support them. This is all about interoperability with existing infrastructure.
I see value in the support of server accounts.
However, the DHT-based account-less p2p part seems to redoing work Tox has done.
Why not use their efforts and experience? They offer their core separately and Ring could be a client for it.
However, the DHT-based account-less p2p part seems to redoing work Tox has done.
Why not use their efforts and experience? They offer their core separately and Ring could be a client for it.
That would duplicate most of our code and we chose not to do so. We currently have an unified architecture that handle both existing sip infrastructure and the distributed one. The distributed part is less or more done, it isn't a big part of the code (about 4% according to a quick rexgex) compared to SIP. We currently use an open network model, but will switch to a closed one based on the cryptographic chain of trust in the coming weeks. That about all there is to it, everything else is SIP/ICE/UPnP/TLS/RTP.
> You wouldn't have had to write that code if using Tox were chosen in the first place.
First of all, it is important to understand that Ring is based on SFLphone. Our team have over 10 years of experience (and code) working with the existing SIP infrastructure. Have an inter-operable SIP based decentralized network is really the whole point of doing what we do.
> Can you give more details on this? (please note that this section talk about features in development, it can still change)
The classical phone network is an open system. Everybody call call everybody, some for emails. This can cause some issues, such as tele-marketing and scam (+ spam, called "SPIT" in the VoIP community). Some other IM networks (MSN messenger, Skype, in fact, most of them) use the opposite. You can only open communication with people who are whitelisted. Traditional SPAM methods are mostly useless on most VoIP media such as voice and images as there is no "ahead of time" processing (everything is RTC). A distributed server-less network also cannot ban accounts, there is none. With IPv6, an IP based blocklist is also impossible.
There is a bunch of ways to fix those issues. One is to build a validation network be asking the peers you currently trust to validate new persons. The downside of this is some serious anonymity issues. You basically tell the world who is calling you. The second option is to use a chain of trust. There is multiple ways this can be implemented. First, it can be done on the DHT itself. You only talk to nodes that are signed by a certificate authority you whitelisted and use TLS revocation and other protocol features to manage a pseudo-clean distributed closed-network from which intruders are banned. The second way is to use the full "global" DHT, but only allow calls signed by a trusted authority. For example, this allow a small startup to sign a bunch of certificates, place them on the DHT and let employees call each other. This network will be about as insulated from unwanted external calls as a private SIP server.
Obviously, those 3 strategies are complementary and can be combined to eliminate SPIT and to a certain extent third party meta-data collection.
First of all, it is important to understand that Ring is based on SFLphone. Our team have over 10 years of experience (and code) working with the existing SIP infrastructure. Have an inter-operable SIP based decentralized network is really the whole point of doing what we do.
> Can you give more details on this? (please note that this section talk about features in development, it can still change)
The classical phone network is an open system. Everybody call call everybody, some for emails. This can cause some issues, such as tele-marketing and scam (+ spam, called "SPIT" in the VoIP community). Some other IM networks (MSN messenger, Skype, in fact, most of them) use the opposite. You can only open communication with people who are whitelisted. Traditional SPAM methods are mostly useless on most VoIP media such as voice and images as there is no "ahead of time" processing (everything is RTC). A distributed server-less network also cannot ban accounts, there is none. With IPv6, an IP based blocklist is also impossible.
There is a bunch of ways to fix those issues. One is to build a validation network be asking the peers you currently trust to validate new persons. The downside of this is some serious anonymity issues. You basically tell the world who is calling you. The second option is to use a chain of trust. There is multiple ways this can be implemented. First, it can be done on the DHT itself. You only talk to nodes that are signed by a certificate authority you whitelisted and use TLS revocation and other protocol features to manage a pseudo-clean distributed closed-network from which intruders are banned. The second way is to use the full "global" DHT, but only allow calls signed by a trusted authority. For example, this allow a small startup to sign a bunch of certificates, place them on the DHT and let employees call each other. This network will be about as insulated from unwanted external calls as a private SIP server.
Obviously, those 3 strategies are complementary and can be combined to eliminate SPIT and to a certain extent third party meta-data collection.
In all honesty, the decision was taken by the project sponsor and is final. We built this https://github.com/savoirfairelinux/opendht and it is already used by some other projects distributed outside of Savoir-faire Linux. So far things look well for OpenDHT so I don't think Savoir-faire Linux will change its mind of the decision at this point. I know you think this is a duplicated effort, but it might not be as true as you think. I respect and understand your frustration, but the decision is final.
However, do you have a link about the Tox 4chan DOS? A quick Google search failed to turn interesting results.
However, do you have a link about the Tox 4chan DOS? A quick Google search failed to turn interesting results.
I respect your effort to implement an open inter-operable SIP based network.
I only referred to the code that implements the p2p DHT part. That part was duplication of effort.
Now, you are talking about a serious and interesting problem in open systems: spam/spit/...
However, Tox faces the same problem. Their network was attacked at least once from the 4chan community. And they came up with a solution. Their solution doesn't force you to tell anybody your contacts and doesn't need certificate authorities.
How about talking with them about the problem to join efforts?
The Tox people are very open to other people using Tox just as a transportation core.
I'd just be unhappy to have another DHT-based communication platform that didn't talk to the other players first.
I only referred to the code that implements the p2p DHT part. That part was duplication of effort.
Now, you are talking about a serious and interesting problem in open systems: spam/spit/...
However, Tox faces the same problem. Their network was attacked at least once from the 4chan community. And they came up with a solution. Their solution doesn't force you to tell anybody your contacts and doesn't need certificate authorities.
How about talking with them about the problem to join efforts?
The Tox people are very open to other people using Tox just as a transportation core.
I'd just be unhappy to have another DHT-based communication platform that didn't talk to the other players first.
That would duplicate most of our code
will switch to a closed one based on the cryptographic chain of trust
Anyway, I still think you should try to join efforts.
@madez: can you explain how you decide that decentralized account management is an advantage on federated?
If I may give my take on this:
Federated: Provide a little better anonymity as many operations are done behind firewalls/NAT/VPNs rather than using public data and point to point sockets. However it has a single point of failure for each nodes and switching from one federated node to another is either problematic or impossible. The federated node can also fall and shut down at anytime.
Distributed: Doesn't required accounts. Base identity on cryptography rather than a web service. It use point to point or point to proxy to point communication. Some meta datas, such who talk to who, when and for how much time are available to anyone (cough...) who can tap on ISP connection metadatas. This service is more robust and cannot really be taken down in ways that cannot be fixed.
Ring support both federated SIP networks and the distributed DHT network (and a mix of both).
(the anonymity problem can be mitigated using tor like onion routing for the negotiation, but it is unrealistic to use real time communication over an onion network. [D]DOS attacks can be handled in a variety of ways, so are DHT trashing ones, bittorrent is still alive and well).
Federated: Provide a little better anonymity as many operations are done behind firewalls/NAT/VPNs rather than using public data and point to point sockets. However it has a single point of failure for each nodes and switching from one federated node to another is either problematic or impossible. The federated node can also fall and shut down at anytime.
Distributed: Doesn't required accounts. Base identity on cryptography rather than a web service. It use point to point or point to proxy to point communication. Some meta datas, such who talk to who, when and for how much time are available to anyone (cough...) who can tap on ISP connection metadatas. This service is more robust and cannot really be taken down in ways that cannot be fixed.
Ring support both federated SIP networks and the distributed DHT network (and a mix of both).
(the anonymity problem can be mitigated using tor like onion routing for the negotiation, but it is unrealistic to use real time communication over an onion network. [D]DOS attacks can be handled in a variety of ways, so are DHT trashing ones, bittorrent is still alive and well).
Savoir-Faire Linux are a local Montréal company with a lot of clout. I don't consider their promises empty, and I'm excited to see them working on this.
Fairly thin on description on what it actually is. But according to the botttom of the page this is SFLphone:
http://en.wikipedia.org/wiki/SFLphone
http://en.wikipedia.org/wiki/SFLphone
Seems to be the case:
https://projects.savoirfairelinux.com/projects/ring/wiki
However the interesting part is the new decentralized "DHT calls". I wonder how well it works.
https://projects.savoirfairelinux.com/projects/ring/wiki
However the interesting part is the new decentralized "DHT calls". I wonder how well it works.
There's a fair amount of criticism brought up here, but I'd like to say that there are bunch of things that looks very promising, at least in the OS X version. Lots of software like this sucks terribly from a usability perspective, but here you have a nice web page (yeah, you need screenshots), a beautiful icon and a usable GUI.
What I'd REALLY like to see is a way to share one or multiple folders of files with my private darknet. If that's possible or not with the technology you use, I don't know. I've been missing a WASTE[1] like communication tool for as long as I can remember.
I guess one of your "competitors" will be Tox. But going to https://tox.im/ I still can't just download a client without going to a messy wiki and get nightly binaries. How many casual users know what a binary is?
[1] https://en.wikipedia.org/wiki/WASTE
What I'd REALLY like to see is a way to share one or multiple folders of files with my private darknet. If that's possible or not with the technology you use, I don't know. I've been missing a WASTE[1] like communication tool for as long as I can remember.
I guess one of your "competitors" will be Tox. But going to https://tox.im/ I still can't just download a client without going to a messy wiki and get nightly binaries. How many casual users know what a binary is?
[1] https://en.wikipedia.org/wiki/WASTE
Pity, I get a 403 on http://gpl.savoirfairelinux.net/ring-download/mac_osx/ring-n....
second that. please fix
What are the advantages compared to tox?
Ring aim at being both standard compliant and (optionally) decentralized. Please check comment https://news.ycombinator.com/item?id=9511782
Or Jitsi. There are plenty of "secure and decentralized" free software options. Most people just don't use them.
For account management, Tox offers complete decentralization while Jitsi uses federation.
I think mostly because they don't work seamlessly on desktop/mobile...
The download link for Mac does not work for me.
Tried this instead:
http://gpl.savoirfairelinux.net/ring-download/
Choose a directory from here.
http://gpl.savoirfairelinux.net/ring-download/
Choose a directory from here.
The link on the website should work now:
http://ring.cx/en/documentation/mac-osx-installation
[deleted]
Why not use a memory safe language?
It looks like this is a real christmas tree of protocol implementations in C/C++ facing the network.
It looks like this is a real christmas tree of protocol implementations in C/C++ facing the network.
Seems legit.
I tried the windows version. It hung after I entered a username.
I unfortuantely didn't understand what this was.
[deleted]
[deleted]
antocv(2)
When I click through on one of the blog posts I see:
"Advanced users can also help to correct problems: we welcome contributions. We expect people to tell us what needs to be corrected, but they can also do it and submit their patches. This is the way it worked with SFLphone and it works pretty well."
So you have no idea IF there are any problems, or do you know that there ARE problems, but you assume they will be corrected soon? If any of the above then how can you state "Ring gives you a ... an unmatched level of privacy."?
I am sorry to be negative about something that seems like it has our privacy at heart, but promising privacy when it might not be there at all is reckless. We in the first world have issues like "I don't want my e-mails scanned by companies" or "I don't want companies to see what I write", but in other parts of the worlds you can be killed if the wrong piece of communication falls in certain hands. So it is pretty important to get it right. You (Ring) provide no information on the site about the state of the code, reviews being done, etc.