Add a warning to the Ricochet description

[ghost]

ricochet-im/ricochet#579

It's already dead.

[ilovelinux]

It's not dead. As I answered to you in the issue you referenced and in ricochet-im/ricochet#578, Ricochet is sicure and development is still going on. There are no reasons to remove it from "Encrypted Instant Messanger".

[ghost]

@ilovelinux Are you blind? You are not a ricochet developer anyway. Read.

[ghost]

Related website, prism-break.org, removed Ricochet. What about you?

prism-break/prism-break#1975

[ghost]

I don't think this should be removed as there's nothing to cause reason that it does not work. The security of this mostly uses Tor Hidden Services. Perhaps a warning about making sure that you're using the latest version of Tor and not the bundled binary would be helpful.

The program did undergo an audit in 2016.

It is inevitable that more complex clients such as the proprietary options are going to be able to support other features at the cost of security. It's probably the best choice for avoiding metadata collection at this point in time. Not everyone needs A/V, server side logs, multi-device etc.

Perhaps we could keep an eye on https://redmine.tails.boum.org/code/issues/8173

[ghost]

I second that we should add a notice regarding using a new version of Tor. I think the only publicly known vulns in the main ricochet client right now are just in the Tor version it uses.

[ghost]

👍 Can anyone create a PR adding what @beardog108 mentioned?

[ghost]

How does this look:

[ghost]

Looks good! The only change I'd make is: [icon]See below -> See below: [icon] Updating the Tor binary included with Ricochet.

So: [Danger] Always keep Tor up to date. See below: [icon] Updating the Tor binary included with Ricochet

And maybe add a command to copy it on Linux and OS X? Hm, maybe a symlink would be better, because updating Tor browser would update the binary for Ricochet as well? And can't the tor binary location be changed in Ricochet's settings? It feels kinda hacky to copy the binary.

The symlink command would look like this:

$ mv ~/Downloads/ricochet/tor ~/Downloads/ricochet/tor.old
$ ln -s ~/Downloads/tor-browser_en-US/Browser/TorBrowser/Tor/tor ~/Downloads/ricochet/tor

[ghost]

Looks good! The only change I'd make is: [[icon] See below](#) -> See below: [[icon] Updating the Tor binary included with Ricochet](#).

So: [Danger] Always keep Tor up to date. See below: [icon] Updating the Tor binary included with Ricochet

Easy done.

And maybe add a command to copy it on Linux and OS X? Hm, maybe a symlink would be better, because updating Tor browser would update the binary for Ricochet as well? And can't the tor binary location be changed in Ricochet's settings? It feels kinda hacky to copy the binary.

It would be better to delete the Tor binary included with Ricochet as there's absolutely no reason to use an old vulnerable version of Tor. It would be better for Ricochet to not open than to risk it using a vulnerable version of Tor.

For MacOSX and Linux it should be sufficient to just "delete" the bundled Tor binary as long as Tor is in the $PATH. Ricochet then will fallback to the binary in the $PATH.

I would do this by using the rm command and using sed to append the path from the Tor Browser's Tor binary to the user's profile $PATH. From the README included in the Linux release:

You do not need to manually run or configure tor. An unmodified tor binary
is included with this package, and Ricochet will run it automatically,
similiar to Tor Browser. There isn't any option to use a system tor daemon,
but Ricochet will use the tor binary from PATH if the bundled copy is removed.

There doesn't seem to be a way within the configuration file or within the user interface to change the location of where the Tor binary is located. On Windows it seems that it's hard coded. I think copying it will be the only solution for Windows without making changes to the Ricochet source.

See: https://github.com/ricochet-im/ricochet/blob/master/src/tor/TorManager.cpp#L274

Does this seem like an acceptable solution to you?

[ghost]

Great. Since it has a fallback to PATH, there's no need to create symlinks. Though which tor is part of PATH? The one from the browser? The one installed using apt(-get) for example? If the latter then it should be noted that updating Tor Browser won't update the other tor (likely).

On my OS, there's:

a) /home/ubuntu/tor-browser_en-US/Browser/TorBrowser/Tor/tor
b) /usr/sbin/tor -> /usr/bin/tor

For me, tor is the one in sbin.

$ which tor
/usr/sbin/tor

I would do this by using the rm command

Maybe mv foo foo.old is better since if the following commands don't work / break something, there will still be a recoverable (though potentially insecure) backup without having to reinstall Ricochet.

[ghost]

When referring to using rm on the Linux platform I meant to delete ricochet/tor assuming they installed it from ricochet-1.1.4-linux-x86_64.tar.bz2.

If you installed Ricochet through apt-get you're going to find that it doesn't include Tor and will depend on it instead. The maintainer will keep that up to date.

On my OS, there's:

a) /home/ubuntu/tor-browser_en-US/Browser/TorBrowser/Tor/tor
b) /usr/sbin/tor -> /usr/bin/tor

Unless 'a' i in your path it's never going to be found. 'b' would be used. As /usr/bin and /usr/sbin are in your path whatever is first in your $PATH would get used. You'd have to put ~/tor-browser_en-US/Browser/TorBrowser/Tor/tor first.

I suppose it would just be safer to make a symlink ie ln -s ~/tor-browser_en-US/Browser/TorBrowser/Tor/tor ~/ricochet/tor then we don't have to worry about if they've installed Tor through apt-get.

It's fairly safe to assume on MacOSX that the Tor binary will be in Applications assuming the user dragged the .app into their /Applications directory ie.

/Applications/Ricochet.app/Contents/MacOS/tor
/Applications/Tor Browser.app/Contents/Resources/TorBrowser/Tor/tor

[ghost]

When referring to using rm on the Linux platform I meant to delete ricochet/tor assuming they installed it from ricochet-1.1.4-linux-x86_64.tar.bz2.

I meant to keep a copy of the tor version that ricochet uses. Just a small detail, not important.

[Nurmagoz]

better removing ricochet is outdated as hell and there are many bugs inside it and Tor new versions not supported by it. Wonder why the hell its still hanging there.

[ghost]

better removing ricochet is outdated as hell

It still works, does it not? It also has been audited by NCC.

and there are many bugs inside it

Such as? All software has bugs, this is not sufficient reason to remove it. If we did that we would have nothing left. Unless they are directly related to security and are not fixed, as in do X de-anonymise user Y. Considering anonymity is one of Ricochet's selling points vs other messengers.

and Tor new versions not supported by it.

My understanding was it still worked with Hidden Services v2 does it not? Documentation was being improved to instruct how to replace the binary with a newer version.

Wonder why the hell its still hanging there.

Is there something better that uses HiddenServices? On a side note, I am curious about https://cwtch.im however it is still firmly experimental at the moment.

[Nurmagoz]

It still works, does it not? It also has been audited by NCC.

working with dying soul. i dunno what kind of a joke of audition is this.

Such as? All software has bugs, this is not sufficient reason to remove it. If we did that we would have nothing left. Unless they are directly related to security and are not fixed, as in do X de-anonymise user Y. Considering anonymity is one of Ricochet's selling points vs other messengers.

yeah but bugs in this case wont fix inside ricochet stuff from 2011 ... example im facing chat deletion,contact removal issue, tor not updated and 2.x has alot of horrible hidden services issues... no way to be considered reliable. Good replacement is Tox Chat.

My understanding was it still worked with Hidden Services v2 does it not? Documentation was being improved to instruct how to replace the binary with a newer version.

yes hidden services v2 still working with Tor 3.x, but the issue when you are using Tor 2.x and using onion v2 = thats fucked.

Is there something better that uses HiddenServices? On a side note, I am curious about https://cwtch.im however it is still firmly experimental at the moment.

nope. and cwtch im sure wont be much.

[ghost]

working with dying soul. i dunno what kind of a joke of audition is this.

You're welcome to check out the code and make some of the improvements you desire. I'm sure your PRs will be appreciated. Also Ricochet Security Assessment February 15, 2016 – Version 1.2.

yeah but bugs in this case wont fix inside ricochet stuff from 2011 ... example im facing chat deletion,contact removal issue,

The bug poster hasn't provided enough information, see my reply ricochet-im/ricochet#593 (comment).

Maybe you could do that instead of running around purporting to be a Whonix developer when you're not and have made no commits to the project.

tor not updated and 2.x has alot of horrible hidden services issues... no way to be considered reliable.

You could pay for a bug bounty. That would certainly encourage someone to move a bit faster in completing ricochet-im/ricochet#575

tor not updated and 2.x has alot of horrible hidden services issues... no way to be considered reliable. Good replacement is Tox Chat.

Considering the authors of Tox clearly state it is experimental it cannot in good faith be recommended anything more than as experimental at this point. In particular:

Keep in mind that these clients are alpha software under heavy development, and are probably not ready for day-to-day use. Because of how significantly the code is still changing, a professional audit hasn't yet been started.

What it sets out to do is significantly more complex than Ricochet which mostly leaves the heavy lifting crypto to Tor. I doubt an audit will occur before the documentation (TokTok) is completed. Audits cost a lot of money and are usually done in the final stage of development after protocol design has been stabilized and frozen.

Additionally as I commented in https://github.com/privacytoolsIO/privacytools.io/issues/736#issuecomment-456901644 it has already been added to the website. Looking at your history it seems you have a problem with using the search function (many of your opened issues have been closed as DUPLICATE).

nope. and cwtch im sure wont be much.

Are you a fortune teller?

[Nurmagoz]

You're welcome to check out the code and make some of the improvements you desire. I'm sure your PRs will be appreciated. Also Ricochet Security Assessment February 15, 2016 – Version 1.2.

not reliable. since the project havent been active since more than 3 years, plus the one who involved there is the same maintainer of Ricochet itself who left it and run away.. (are you kidding me..) .

The bug poster hasn't provided enough information, see my reply ricochet-im/ricochet#593 (comment).
Maybe you could do that instead of running around purporting to be a Whonix developer when you're not and have made no commits to the project.

Anyone whos running ricochet know how sucks its performance and stability (unless the user too blind to see that) , no need logs to prove it. and im just a user of whonix not a developer.

You could pay for a bug bounty. That would certainly encourage someone to move a bit faster in completing ricochet-im/ricochet#575

I wont pay a dollar for a dead project which there are no known maintainers to it anymore.

Considering the authors of Tox clearly state it is experimental it cannot in good faith be recommended anything more than as experimental at this point.

Well maybe you missed that as well in Ricochet main page:

Be careful

Ricochet is an experiment. 

So your argument of experimental or not has no value.

Additionally as I commented in #736 (comment) it has already been added to the website. Looking at your history it seems you have a problem with using the search function (many of your opened issues have been closed as DUPLICATE).

And many others wont fix , and many others still open ... so you are not making any sense at all.

Are you a fortune teller?

Yes

[ghost]

not reliable. since the project havent been active since more than 3 years, plus the one who involved there is the same maintainer of Ricochet itself who left it and run away.. (are you kidding me..) .

Well unless you can point to some new 0days out there, I think the report from NCC is still valid enough. As far as I am aware the only vulnerabilities relate to the old Tor binary distributed (which can be replaced) and not Ricochet itself.

The bug poster hasn't provided enough information, see my reply ricochet-im/ricochet#593.

Anyone whos running ricochet know how sucks its performance and stability (unless the user too blind to see that) , no need logs to prove it.

That issue you cited had nothing to do with performance. It was a null pointer exception.

Maybe you could do that instead of running around purporting to be a Whonix developer when you're not and have made no commits to the project.

and im just a user of whonix not a developer.

You didn't make any effort to correct people when they assumed you were. Using the name "whonix_anonymous_os" , "Whonix" and their project logo would give off that vibe. When you then suggest things like collaboration, people would assume you had something to do with the project as that would be something for the actual project members to decide. 1, 2, 3, 4

I wont pay a dollar for a dead project which there are no known maintainers to it anymore.

Why don't you become it's maintainer? If there was a bug bounty I'm sure someone would make some improvements. The code isn't all that mystical, it just needs someone's time.

That being said it looks like cwtch.im is getting quite a few commits so this might very well be a healthy fork with some new features. I hope it works out well for them.

Considering the authors of Tox clearly state it is experimental it cannot in good faith be recommended anything more than as experimental at this point.

Well maybe you missed that as well in Ricochet main page:

Be careful
Ricochet is an experiment.

So your argument of experimental or not has no value.

Yes but it's far less drastic than what Tox proposes (own crypto) vs using HiddenServices. I wish them good fortune as well and have used qTox a number of times for video conferencing.

Additionally as I commented in https://github.com/privacytoolsIO/privacytools.io/issues/736 it has already been added to the website. Looking at your history it seems you have a problem with using the search function (many of your opened issues have been closed as DUPLICATE).

And many others wont fix , and many others still open ... so you are not making any sense at all.

And if you'd actually used the search option you'd see that Tox is already on the privacytools.io website like I told you in https://github.com/privacytoolsIO/privacytools.io/issues/736#issuecomment-456901644

Anyway I've wasted enough time on you.

[ghost]

Clearly as there's been a lack of understanding here, I suggest https://github.com/privacytoolsIO/privacytools.io/issues/746

[Mikaela]

I tried to look into Ricochet for a moment and I think I agree with adding a warning or even removing it entirely.

• No commits since August 2017 https://github.com/ricochet-im/ricochet/commits/master
• Latest mailing list entry is from Mon, 16 Jul 2018 15:13:00 +0000 asking if there will be a new release and there are no responses https://lists.riseup.net/www/arc/ricochet-dev/2018-07/msg00000.html (via A mailing list would be really great!  ricochet-im/ricochet#388)
• discussion on its future doesn't have anyone from the project commenting (or GitHub doesn't show the member flair) On Ricochet's Future ricochet-im/ricochet#425
• Ricochet is said to be fingerprintable (Prevent fingerprinting to improve anonymity & UX ricochet-im/ricochet#351 (comment)) and as it sems to be HSv2-only (Hidden Services v3 ricochet-im/ricochet#575) I think this issue is only getting worse as I recall seeing that Tor nowadays defaults to creating version 3 hidden services unless HSv2 is specified separately.
  • EDIT: Tor 0.3.5 https://blog.torproject.org/new-releases-tor-0357-03410-and-03311 and I commented there to ask about this.
• ships a version of Tor that was old even in 2016? Update Tor in bundles ricochet-im/ricochet#487

Other issues getting my attention that may be interesting, but irrelevant to this issue:

• There aren't reproducible builds Reproducible builds? ricochet-im/ricochet#323
• No support for multiple devices Multiple devices - one account ricochet-im/ricochet#406
• Feature request for VoIP Adding VOIP feature ricochet-im/ricochet#308 (this would probably be more relevant to https://github.com/privacytoolsIO/privacytools.io/issues/746)

[Vincevrp]

I tried to look into Ricochet for a moment and I think I agree with adding a warning or even removing it entirely.

I agree on removing it @Shifterovich.

[ghost]

I'm too busy rn to look into it enough but there's so many good IM tools that removing the less-than-ideal ones does more good than harm. Feel free @Vincevrp

[ghost]

I tried to look into Ricochet for a moment and I think I agree with adding a warning or even removing it entirely.

• No commits since August 2017 https://github.com/ricochet-im/ricochet/commits/master

• Latest mailing list entry is from Mon, 16 Jul 2018 15:13:00 +0000 asking if there will be a new release and there are no responses https://lists.riseup.net/www/arc/ricochet-dev/2018-07/msg00000.html (via ricochet-im/ricochet#388)

• discussion on its future doesn't have anyone from the project commenting (or GitHub doesn't show the member flair) ricochet-im/ricochet#425

• Ricochet is said to be fingerprintable (ricochet-im/ricochet#351 (comment)) and as it sems to be HSv2-only (ricochet-im/ricochet#575) I think this issue is only getting worse as I recall seeing that Tor nowadays defaults to creating version 3 hidden services unless HSv2 is specified separately.

• EDIT: Tor 0.3.5 https://blog.torproject.org/new-releases-tor-0357-03410-and-03311 and I commented there to ask about this.

Yes these are the major issues here, now particularly if HSv3 is default. I can see a time sometime in the future where HSv2 may be deprecated entirely from newer Tor releases. I think at this point it's only a matter of when.

Removing it would also solve https://github.com/privacytoolsIO/privacytools.io/pull/618 meaning that would no longer be needed.

It does seem there's not going to be any new development. If you look at this ticket ricochet-im/ricochet#574 @s-rah seems to be busy developing cwtch which is the next iteration of Ricochet.

• ships a version of Tor that was old even in 2016? ricochet-im/ricochet#487

Which kind of links to the last point.

Other issues getting my attention that may be interesting, but irrelevant to this issue:

There aren't reproducible builds ricochet-im/ricochet#323

A lot of things aren't reproducible unfortunately.

• No support for multiple devices ricochet-im/ricochet#406

This one would require a complete redesign, as it would no longer be peer-to-peer you'd need some sort of decentralized net or server infrastructure to store messages. It may very well be that cwtch.im is able to succeed here. Too early to be added however. Work does seem to be occurring though https://git.openprivacy.ca/cwtch.im/cwtch/commits/master

On a side note Ricochet is still included in Debian https://packages.debian.org/sid/ricochet-im but that's only because nobody has investigated it enough to find an exploit, get a CVE and then have it's unmaintained nature brought into the spotlight.

It does appear that it's not going to be added to Tails any time soon https://redmine.tails.boum.org/code/issues/8173

• Feature request for VoIP ricochet-im/ricochet#308 (this would probably be more relevant to 💬 Discussion | Change Encrypted Instant Messenger to Zero Metadata IM. #746)

This one is kind of lol, what's the point of an anonymous messenger over Tor if your voice can be identified.

[ghost]

I see the argument for removing it and agree with most points, however it is sad to see it unmaintained and removed since it is currently one of the only decent (in design) Tor-default, p2p chat applications.

I say we put it in worth mentioning with the warning to update the tor binary. However i think i'm a little outnumbered, so i'll just remove it if no one else makes a pr soon.

[ghost]

(in design) Tor-default, p2p chat applications.
I say we put it in worth mentioning with the warning to update the tor binary. However i think i'm a little outnumbered, so i'll just remove it if no one else makes a pr soon.

I do like the way that Ricochet works. Nothing really quite comes close to it in regard to metadata resistance.

I think it's a less of a case of it being unmaintained, and more of a case of the current maintainers are active on the successor project, cwtch which aims to "fix" some of the issues with Ricochet (which was basically TorChat with a nicer UI). One of those things being updating the Tor binary, multi device support and offline messaging. Unfortunately it is still very 'alpha' at this state. Using something that is that experimental may very well be detrimental.

I do think we need to reorganize the instant messenger section. How we do that is a topic of discussion. https://github.com/privacytoolsIO/privacytools.io/issues/746 https://github.com/privacytoolsIO/privacytools.io/issues/729 because all things simply are not equal.

[E3V3A]

I really suggest all of you to read THIS POST regarding Ricochet by @s-rah.

➡️ Cwtch.

and hosted at:

• https://cwtch.im/
• https://git.openprivacy.ca/cwtch.im/cwtch

[ghost]

As for this project, there is clearly some maintenance to be done to prevent longer-term rot. Standard ricochet packagings e.g. debian should , AFAICR, prefer system installed/newer Tor versions. In my opinion, there is no reason in the short term and in many cases to consider Ricochet unsafe to use,but it is experimental and volunteer driven.

This is the most relevant part IMO. Good reason to keep/put it in worth mentioning

[Mikaela]

Is having up-to-date Tor enough if the software itself doesn't support hidden service version 3? Has anyone tested that it still works with Tor versions that default to HSv3 (or it uses HSv2 explicitly and isn't affected by the default changing)?

If the answer is yes to both, then I think it would be OK to keep as worth mentioning on Debian, but will most of Windows users start updating the Tor binary? (More relevant question might be whether they would install Ricochet at all though.)

[Mikaela]

I opened an issue to ask if Ricochet should instead be replaced by Cwtch (https://github.com/privacytoolsIO/privacytools.io/issues/781).

[ghost]

I really suggest all of you to read THIS POST regarding Ricochet by @s-rah.

Ah yes, that more a less repeats what was said in ricochet-im/ricochet#574 (comment) that I linked in my comment https://github.com/privacytoolsIO/privacytools.io/issues/474#issuecomment-471776595

Is having up-to-date Tor enough if the software itself doesn't support hidden service version 3? Has anyone tested that it still works with Tor versions that default to HSv3 (or it uses HSv2 explicitly and isn't affected by the default changing)?

I decided to test this between two hosts. Host 1 from the Debian repositories and Host 2 a Windows machine. Here's what I started with:

[
  {
    "Machine": "1",
    "OS": "Debian 9",
    "Versions": {
      "Ricochet": "1.1.4",
      "Tor": "0.2.9.16 (git-9ef571339967c1e5)",
      "Libevent": "2.0.21-stable",
      "OpenSSL": "1.1.0j",
      "Zlib": "1.2.8"
    }
  },
  {
    "Machine": "2",
    "OS": "Windows 10",
    "Versions": {
      "Ricochet": "1.1.4",
      "Tor": "0.2.8.9",
      "Libevent": "2.0.22-stable",
      "OpenSSL": "1.0.2j",
      "Zlib": "1.2.8"
    }
  }
]

Everything seemed to work. However Host 2 is vulnerable as it is using the shipped copy of Tor. Note to see the version number one needs to add Log notice file C:\Users\user\Desktop\tor.log to your torrc to enable logging.

Now updating the Windows version using the binaries from torbrowser-install-win64-8.0.6_en-US.exe

18,21c18,21
<       "Tor": "0.2.8.9",
<       "Libevent": "2.0.22-stable",
<       "OpenSSL": "1.0.2j",
<       "Zlib": "1.2.8"
---
>       "Tor": "0.3.5.7 (git-9beb085c10562a25)",
>       "Libevent": "2.1.8-stable",
>       "OpenSSL": "1.0.2q",
>       "Zlib": "1.2.11"

Things were not so great. The first error I got was

The code execution cannot proceed because zlib1.dll was not found. Reinstalling the program may fix the problem.

The code execution cannot proceed because libevent-2-1.6.dll was not found. Reinstalling the program may fix the problem.

So I copied the binaries zlib1.dll, libevent-2-1-6.dll, libevent_core-2-1-6.dll, libevent_extra-2-1-6.dll also into Ricochet directory ie C:\Users\user\AppData\Local\Ricochet.

Unfortunately then I got:

The application was unable to start correctly (0xc000007b). Click OK to close the application.

So it seems its not as simple as it was back then https://github.com/privacytoolsIO/privacytools.io/pull/618 to just update tor.exe.

If the answer is yes to both, then I think it would be OK to keep as worth mentioning on Debian, but will most of Windows users start updating the Tor binary? (More relevant question might be whether they would install Ricochet at all though.)

Well I guess that depends on whether we can solve the above issue.

[blacklight447]

as ricochet has been demoted to worth mentioning and now also has several warnings, i think it is right to close this issue

[odiferousmint]

I second that we should add a notice regarding using a new version of Tor. I think the only publicly known vulns in the main ricochet client right now are just in the Tor version it uses.

See below.

Is having up-to-date Tor enough if the software itself doesn't support hidden service version 3? Has anyone tested that it still works with Tor versions that default to HSv3 (or it uses HSv2 explicitly and isn't affected by the default changing)?

No, it is not enough, because Ricochet uses RSA1024[1] instead of ED25519-V3[2] as KeyType.

[1] https://github.com/ricochet-im/ricochet/blob/master/src/tor/AddOnionCommand.cpp#L56
[2] https://github.com/torproject/torspec/blob/master/control-spec.txt#L1608