Ricochet inclusion in TAILS Linux?

[PacketSmuggler]

I have been using Ricochet on OSX 10.11.6, no complaints on stability, don't have enough friends to have an opinion on these other complaints about message retention, etc, I see when scanning the open issues.

I think that it would be very good for both Ricochet and TAILS if the work could be done such that TAILS will include it.

https://labs.riseup.net/code/issues/8173

Briefly, they want software that is included in the base Debian install, which should be fairly simple, and they want Ricochet to use the Tor stack that is part of TAILS, rather than launching its own.

The second requirement strikes me as perhaps being complex, unless Ricochet devs are willing to add a Use Ours/Use Tor default config option.

[special]

There's some older discussion on this in #31, but it's so out of date that I am going to break my pattern and keep this issue.

Ricochet is packaged for Debian. We use ADD_ONION when available now, so there's no problem with storing hidden service files.

If TOR_CONTROL_PORT (or equivalent) is set in the environment, Ricochet will use that Tor instance instead of launching its own, which is the same behavior as Tor Browser.

Tails will need to have a control port filter they are comfortable with, and allow the commands that Ricochet uses. It looks like this isn't done yet?

I believe Tails will still block Ricochet from listening on a localhost TCP port for its hidden service. I don't know what solution they prefer. One option is to use unix sockets -- the Ricochet code exists, but is held back due to some other problems (https://github.com/ricochet-im/ricochet/issues/225#issuecomment-207282447). They would also need to allow Ricochet to create a unix socket in a location that is reachable by the Tor daemon.

It's worth noting that Subgraph has Ricochet working with their system Tor instance, control port filter, and sandboxing. A lot of the progress on this issue has been thanks to them.

[special]

Latest from the TAILS side indicates that everything could align to include Ricochet around TAILS 3.0 (~2017-06). They need their Debian version update to land before Ricochet packages are available.

[epidemics-scepticism]

I wrote a patch (I'm (kinda hackily?) not using TOR_CONTROL_PORT and instead just giving it an /etc/skel based ricochet.json so the first launch should generate a new key, a specific listening port and use the existing Tor instance) along with a control port filter profile.

It's using one of the set of ports that were punched in iptables to allow OnionShare to work.

Patch is set against stable branch, diff generated from 466e43cfc5b0a34c23d26ec7a80de86f4468a8c9 of the Tails builder git.

ricochet.diff

I've built and tested this and it seems to be working for me. It still requires some work on the Tails side through to give it a Persistence option, so that your key and contacts will persist between sessions.

[herbsmn]

This seems like something worth looking into again now that the Additional Software feature is rolling out in Tails. https://tails.boum.org/news/test_asp-beta/index.en.html

Even if Ricochet isn't shipped in Tails, it'd be nice if it would actually work when installed via the Additional Software feature, but I just tested it out and it doesn't work. I just tried it and I'm getting the same result as was documented here https://labs.riseup.net/code/issues/8173#note-29

[epidemics-scepticism]

It won't work on Tails even with additional software because it needs

1. An onion-grater profile, the control port filter. I have a patch to add this to Tails on the ricochet ticket under Tails.
2. It needs a specific config so that it will only use ports to communicate which are available through the Tails iptables config. I also have a patch for this under the ricochet ticket under Tails.

If you apply my patches to the Tails build repo then build Tails, you'll have a working Tails with ricochet and persistence support.

It will likely never be included in Tails by default at this point though, at least not in the forseeable future, maybe once they base Tails off of sid it will be more feasible.

[jes]

FWIW, I got it working without any patches by simply adding a firewall rule that allows the amnesia user to access anything on localhost. This is convenient for actual usage, but not as secure as the methods described above.

https://incoherency.co.uk/blog/stories/ricochet-tails.html

[traumschule]

Interesting. What happens if you only configure Ricochet to use Tails' Tor daemon?

[jes]

I'm not sure how to try that, but it sounds like it would work if you gave the amnesia user access to the Tor control port. The packaged version of Ricochet tries to start it's own Tor process, I don't know if there's a configuration option to do anything else, but it's not exposed in the UI if there is.

[jes]

I suppose you could make the control-port file with PORT=127.0.0.1:9060 (or whatever port it is), and make the file immutable (chattr +i) and see if Ricochet works. Might be worth playing with.

It would still try to start its own Tor process (which would presumably exit because it can't write to control-port), but as long as Ricochet doesn't notice that its Tor process exited, it would probably end up connecting to the system Tor's control port.

[traumschule]

try

1. ./ricochet ~/.config/ricochet
2. choose Configure
3. Configure 127.0.0.1 and 9050 for the Socks5 proxy
4. Click Connect

This will create (among others) ~/.config/ricochet/tor/torrc with

Socks5Proxy 127.0.0.1:9050

which according to man tor has the effect we want:

  Socks5Proxy host[:port]
      Tor will make all OR connections through the SOCKS 5 proxy at host:port (or host:1080 if port is not specified).

[jes]

That doesn't work as it doesn't allow Ricochet to access Tor's control port. Did you read the method I linked in my post above? I made Ricochet's Tor instance proxy via the system Tor instance (which is what you just suggested) and I added a firewall rule to allow Ricochet to access the control port of its Tor instance.

[traumschule]

Two links that could help: https://tails.boum.org/contribute/design/#index18h3 https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/etc/ferm/ferm.conf

[epidemics-scepticism]

You don't need to edit ferm at all, you just pre-configure ricochet to use the port exceptions that already exist for onionshare. See my pre-existing patch-set for tails builder. I even have patches for persistence on the tails ticket.

[traumschule]

Thanks for the clarifcation! Will ricochet be included in Tails per default? This will help users who are not confident configuring tor themselves. Otherwise we should provide clear instructions in the documentation.

[epidemics-scepticism]

That was my intent, unfortunately it seems unlikely at the moment. The biggest hurdle seems to be installing ricochet at the moment, without some kind of library conflict with other packages. Tails don't want to include it as is, they want more of it included upstream rather than maintained in Tails. But if you're willing to build your own Tails image then it's feasible right now, yes.

[herbsmn]

@epidemics-scepticism does your patch continue to work with the newest Tails releases?

[epidemics-scepticism]

The core of my patch set is still fine.

Current blockers for inclusions:

• Only stretch/stable supports a QT library that doesn't conflict with other Tails' software deps
• Only testing/next-stable is packaged with the AppArmor profile after I got it merged upstream.

As such you'll want to install ricochet from stretch/stable and include the AppArmor patch.

Minor/Annoying things:

• Some of the literal patch files may need rebasing, e.g. the current persistence-setup-patch-patch (an ugly hack to patch Ricochet persistence settings into the Tails persistence setup without the changes being upstream yet) which was done before a lot of updates were made to persistence setup recently.

Unfortunately my build system seems to have keeled over for now, it was getting on in...so I can't actually build a test iso right now to see but all the required components should be there.

Things you need

1. ricochet added to the list of software packages Tails includes
2. a ricochet config file in /etc/skel/ which is pre-configured to use Tor as provided by Tails and listen on ports that are already ready for use in iptables/ferm so ricochet can make the connections it needs to (ricochet -> tor control, ricochet -> tor socks, tor inbound onion -> ricochet).
3. an onion-grater (Tails' control port filter) profile for ricochet so that ricochet can talk to tor and setup the onion services and check status, etc.
4. (optional but a good idea) an apparmor profile for ricochet to restrict its access to the OS in the event of compromise

Things people smarter than me could make better

1. The AppArmor profile is trash.

• I'm stuck between paranoia and wanting maximum interoperability and finding weird /sys/ devices that QT needs access to for rendering on weird graphics platforms is always great and makes me feel really good about my life choices.

2. The current patchset for the ricochet builder to include AppArmor into the debian package can be improved.

• once it's built works for me but always breaks for the current Ricochet maintainer at debian so they're using a dirty hack which shouldn't be required.

3. If we could get apparmor and onion-grater upstreamed then we might be able to just add ricochet via persistent software and it would just work out of the box with the exception of the default config.
4. It'd be great if we didn't need the aforementioned default config, otherwise users end up doing manual editing of JSON files which sucks for most users.

Should we be spending our time on this effort?

It's not actually clear to me that this is a productive use of our time, while Ricochet is perfectly functional the development has gone towards alternative clients now.

There are interesting projects like @s-rah's cwtch which are built on top of the Ricochet protocol will be much more feature rich and should be able to handle things like group chats and more.

Also there are non-Ricochet projects like Briar which try to address many of the same core anonymity/privacy/discoverability issues with the current status quo of messaging services and applications.

I'd recommend looking into how long that Ricochet ticket on Tails' tracker was open for before I picked it up and how long it took me to get it where it currently is...and then how far it still has to go before it's ready to be included.

Is it a good use of our time to commit to this specific implementation of onion-to-onion messaging, for the Tails project and Tails users? How long will this specific implementation still be used (and preferred) into the future?