Description
Details
- Impact
- Normal
Status | Assigned | Task | ||
---|---|---|---|---|
Invalid | Patrick | T444 test if Ricochet IM instructions are functional | ||
Resolved | troubadour | T445 CONTROL_PORT_FILTER_WHITELIST wildcard feature | ||
Resolved | Patrick | T446 research control port filter proxy whiltelist wildcard security implications | ||
Resolved | Patrick | T448 support for Tor control protocol events (setevent) by Control Port Filter Proxy |
Event Timeline
Some major commits made to Ricochet recently. May affect CPFP whitelist:
- Allow configuring external Tor in the environment
If the TOR_CONTROL_PORT environment variable is present, use that
external instance of Tor instead of launching a bundled one.
TOR_CONTROL_HOST and TOR_CONTROL_PASSWD are also available for the
control hostname and password respectively. These variables match
the names used by Tor Browser.
There is no need to configure the SOCKS address; Ricochet will discover
it automatically.
https://github.com/ricochet-im/ricochet/commit/fe8f24aad1779cc798926d980f55f81b52f71683
- Store identity keys in configuration when possible
For Tor >= 0.2.7, we can use ADD_ONION to configure hidden services, so
private keys no longer need to be in separate files on disk. When
possible, stop using those files and store keys only in our
configuration file.
Existing profiles will copy their keys into the configuration file, but
the old files will not be removed yet. Older versions of Tor remain
supported as well, and will always use the filesystem.
https://github.com/ricochet-im/ricochet/commit/f8aeff2f62ed6248e1fa997d06be4000f73b4d16
- Use the ADD_ONION command when Tor is new enough
For versions of Tor that support it, use ADD_ONION instead of SETCONF to
configure hidden services.
https://github.com/ricochet-im/ricochet/commit/f38b266e5e266d9928e0cdafa53edba5e9b93a36
- Allow HiddenService to configure ephemeral services
Refactored the HiddenService class API to handle services that have no
filesystem representation.
https://github.com/ricochet-im/ricochet/commit/4e2a97d0a3107f1b13199fe6e6685893afc474bd
There is a ricochet-im package in debian repos for testing and unstable now: https://packages.debian.org/search?keywords=ricochet-im&searchon=names&suite=all§ion=all
https://github.com/ricochet-im/ricochet/issues/415#issuecomment-220178419
Got it working for a while, but now having issues. Either firewall issues or issue due to mixing jessie / stretch packages.
- https://github.com/Whonix/control-port-filter-python/commit/611c974a9f349ad4a136a2baf479e86276690eca
- https://github.com/Whonix/control-port-filter-python/commit/c7231b54fe0a17cad68342a8385eb2035bea61d3
- https://github.com/Whonix/control-port-filter-python/blob/master/usr/share/tor-controlport-filter/examples/40_ricochet.yml
- https://github.com/Whonix/whonix-ws-firewall/commit/389b4894773bd959c5f98e5fdadc2f9b0753abfa
- https://github.com/Whonix/uwt/commit/2a516b92849f3dd55c0d5cec6a01510f13268c33
- https://github.com/Whonix/uwt/commit/20f9e00db8f8ad9ace67b8aa4626f90b2e9bd9a7
- https://www.whonix.org/wiki/Next#ricochet
Problem is, ricochet picks a random high local port so we actually have to open all incoming workstation ports. Posted a feature request upstream:
https://github.com/ricochet-im/ricochet/issues/30#issuecomment-271646818
I got Ricochet properly working.
I had some troubles with onion-grater which filtered commands needed by Ricochet.
Even with the config file provided in example :
https://github.com/Whonix/onion-grater/blob/master/usr/share/onion-grater-merger/examples/40_ricochet.yml
So I used --complain option to allow all commands.
I'm going to look how onion grater works and make a config file.
I will update this task soon.
So here are all the steps to make ricochet working :
Open Ricochet and close it (it will create all the config files and folders).
Then edit : $HOME/.local/share/Ricochet/ricochet.anondist-orig/ricochet.json :
{ "identity": { "dataDirectory": "data-0", "localListenAddress": "10.152.152.11", "localListenPort": 12345 }, "tor": { "controlAddress": "127.0.0.1", "controlPort": 9151, "socksAddress": "127.0.0.1", "socksPort": 9050 }, "ui": { "combinedChatWindow": true, "language": "", "notificationVolume": 0.75 } }
Don't forget to open the port 12345 on the workstation firewall.
On the gateway create the file /usr/local/etc/onion-grater-merger.d/40_ricochet.yml
--- - exe-paths: - '*' users: - '*' hosts: - '*' commands: GETINFO: - pattern: 'status/circuit-established status/bootstrap-phase' response: - pattern: '250-status/circuit-established=*' replacement: '250-status/bootstrap-phase=NOTICE BOOTSTRAP PROGRESS=100 TAG=done SUMMARY="Done"' GETCONF: - 'DisableNetwork' ADD_ONION: - pattern: 'NEW:(\S+) Port=12345,\S+:(\S+)' replacement: 'NEW:{} Port=12345,{client-address}:{}' - pattern: '(\S+):(\S+) Port=12345,\S+:(\S+)' replacement: '{}:{} Port=12345,{client-address}:{}' DEL_ONION: - '.+' events: STATUS_CLIENT: suppress: true
Edit torrc and create a new onion service :
HiddenServiceDir /var/lib/tor/ricochet/ HiddenServicePort 12345 10.152.152.11:12345 DisableNetwork 1
restart onion-grater and tor.
Ricochet should work now.
What's after :) ?
Tibo (Tibo):
Tibo added a comment.
So here are all the steps to make ricochet working :
Open Ricochet and close it (it will create all the config files and folders).
Then edit : *$HOME/.local/share/Ricochet/ricochet.anondist-orig/ricochet.json* :{
"identity": { "dataDirectory": "data-0", "localListenAddress": "10.152.152.11", "localListenPort": 12345 }, "tor": { "controlAddress": "127.0.0.1", "controlPort": 9151, "socksAddress": "127.0.0.1", "socksPort": 9050 }, "ui": { "combinedChatWindow": true, "language": "", "notificationVolume": 0.75 }}
Probably a manual config is required because otherwise
localListenAddress is set to localhost.
Manual config is not how it is supposed to work. It worked before. This
means there could be a bug in uwt and/or bindp.
references to bindp)
Don't forget to open the port 12345 on the workstation firewall.
On the gateway create the file
*/usr/local/etc/onion-grater-merger.d/40_ricochet.yml*
- exe-paths:
- '*' users:
- '*' hosts:
- '*' commands: GETINFO:
- pattern: 'status/circuit-established status/bootstrap-phase' response:
- pattern: '250-status/circuit-established=*' replacement: '250-status/bootstrap-phase=NOTICE BOOTSTRAP PROGRESS=100 TAG=done SUMMARY="Done"' GETCONF:
- 'DisableNetwork' ADD_ONION:
- pattern: 'NEW:(\S+) Port=12345,\S+:(\S+)' replacement: 'NEW:{} Port=12345,{client-address}:{}'
- pattern: '(\S+):(\S+) Port=12345,\S+:(\S+)' replacement: '{}:{} Port=12345,{client-address}:{}' DEL_ONION:
- '.+' events: STATUS_CLIENT: suppress: true
Edit torrc and create a new onion service :
HiddenServiceDir /var/lib/tor/ricochet/
HiddenServicePort 12345 10.152.152.11:12345
DisableNetwork 1
That should not be required because the onion service is supposed to be
an ephermal Tor onion services created by ricochet which is using Tor
control protocol ADD_ONION to do it (which then is actually talking to
#onion-grater).
What's after :) ?
If you can fix this one, please fix this one.
Oh, my bad...
Probably a manual config is required because otherwise
localListenAddress is set to localhost.Manual config is not how it is supposed to work. It worked before
Yes exactly, and also to set the localListenPort.
Sorry if my question is stupid but, is there a reason to use bindp instead of providing the configuration file ?
I notice that when i'm using bindp :
BIND_PORT=12345 BIND_ADDR="10.152.152.11" LD_PRELOAD=/usr/lib/libindp.so ricochet
I don't see the ADD_ONION command on onion-grater logs and ricochet doesn't work.
10.152.152.11:53654 (filter: 30_autogenerated): -> PROTOCOLINFO 1 10.152.152.11:53654 (filter: 30_autogenerated): <- 250-PROTOCOLINFO 1 10.152.152.11:53654 (filter: 30_autogenerated): <- 250-AUTH METHODS=NULL 10.152.152.11:53654 (filter: 30_autogenerated): <- 250-VERSION Tor="0.3.2.10 (git-0edaa32732ec8930)" 10.152.152.11:53654 (filter: 30_autogenerated): <- 250 OK 10.152.152.11:53654 (filter: 30_autogenerated): -> AUTHENTICATE 10.152.152.11:53654 (filter: 30_autogenerated): <- 250 OK 10.152.152.11:53654 (filter: 30_autogenerated): -> GETCONF DisableNetwork 10.152.152.11:53654 (filter: 30_autogenerated): <- 250 DisableNetwork=0 10.152.152.11:53654 (filter: 30_autogenerated): -> SETEVENTS STATUS_CLIENT 10.152.152.11:53654 (filter: 30_autogenerated): subscribed to event 'STATUS_CLIENT' 10.152.152.11:53654 (filter: 30_autogenerated): <- 250 OK 10.152.152.11:53654 (filter: 30_autogenerated): -> GETINFO status/circuit-established status/bootstrap-phase net/listeners/socks 10.152.152.11:53654 (filter: 30_autogenerated): rewrote response: 250-status/circuit-established=1 250-status/bootstrap-phase=NOTICE BOOTSTRAP PROGRESS=100 TAG=done SUMMARY="Done" 250-net/listeners/socks="127.0.0.1:9050" "10.152.152.10:9050" "10.152.152.10:9100" "10.152.152.10:9101" "10.152.152.10:9102" "10.152.152.10:9103" "10.152.152.10:9104" "10.152.152.10:9105" "10.152.152.10:9106" "10.152.152.10:9107" "10.152.152.10:9108" "10.152.152.10:9109" "10.152.152.10:9110" "10.152.152.10:9111" "10.152.152.10:9112" "10.152.152.10:9113" "10.152.152.10:9114" "10.152.152.10:9115" "10.152.152.10:9116" "10.152.152.10:9117" "10.152.152.10:9118" "10.152.152.10:9119" "10.152.152.10:9120" "10.152.152.10:9121" "10.152.152.10:9122" "10.152.152.10:9123" "10.152.152.10:9124" "10.152.152.10:9125" "10.152.152.10:9150" "10.152.152.10:9152" "10.152.152.10:9153" "10.152.152.10:9154" "10.152.152.10:9155" "10.152.152.10:9156" "10.152.152.10:9157" "10.152.152.10:9158" "10.152.152.10:9159" "10.152.152.10:9160" "10.152.152.10:9161" "10.152.152.10:9162" "10.152.152.10:9163" "10.152.152.10:9164" "10.152.152.10:9165" "10.152.152.10:9166" "10.152.152.10:9167" "10.152.152.10:9168" "10.152.152.10:9169" "10.152.152.10:9170" "10.152.152.10:9171" "10.152.152.10:9172" "10.152.152.10:9173" "10.152.152.10:9174" "10.152.152.10:9175" "10.152.152.10:9176" "10.152.152.10:9177" "10.152.152.10:9178" "10.152.152.10:9179" "10.152.152.10:9180" "10.152.152.10:9181" "10.152.152.10:9182" "10.152.152.10:9183" "10.152.152.10:9184" "10.152.152.10:9185" "10.152.152.10:9186" "10.152.152.10:9187" "10.152.152.10:9188" "10.152.152.10:9189" "127.0.0.1:9100" "127.0.0.1:9101" "127.0.0.1:9102" "127.0.0.1:9103" "127.0.0.1:9104" "127.0.0.1:9105" "127.0.0.1:9106" "127.0.0.1:9107" "127.0.0.1:9108" "127.0.0.1:9109" "127.0.0.1:9110" "127.0.0.1:9111" "127.0.0.1:9112" "127.0.0.1:9113" "127.0.0.1:9114" "127.0.0.1:9115" "127.0.0.1:9116" "127.0.0.1:9117" "127.0.0.1:9118" "127.0.0.1:9119" "127.0.0.1:9120" "127.0.0.1:9121" "127.0.0.1:9122" "127.0.0.1:9123" "127.0.0.1:9124" "127.0.0.1:9125" "127.0.0.1:9150" "unix:/var/run/tor/socks" 250 OK to: 250-status/circuit-established=1 250-status/bootstrap-phase=NOTICE BOOTSTRAP PROGRESS=100 TAG=done SUMMARY="Done" 250-net/listeners/socks="127.0.0.1:9150" 250 OK 10.152.152.11:53654 (filter: 30_autogenerated): <- (multi-line) 250-status/circuit-established=1 250-status/bootstrap-phase=NOTICE BOOTSTRAP PROGRESS=100 TAG=done SUMMARY="Done" 250-net/listeners/socks="127.0.0.1:9150" 250 OK
However when I'm using the manual config to set the listening port and address I see the ADD_ONION command, and ricochet works:
10.152.152.11:53658 (filter: 30_autogenerated): -> PROTOCOLINFO 1 10.152.152.11:53658 (filter: 30_autogenerated): <- 250-PROTOCOLINFO 1 10.152.152.11:53658 (filter: 30_autogenerated): <- 250-AUTH METHODS=NULL 10.152.152.11:53658 (filter: 30_autogenerated): <- 250-VERSION Tor="0.3.2.10 (git-0edaa32732ec8930)" 10.152.152.11:53658 (filter: 30_autogenerated): <- 250 OK 10.152.152.11:53658 (filter: 30_autogenerated): -> AUTHENTICATE 10.152.152.11:53658 (filter: 30_autogenerated): <- 250 OK 10.152.152.11:53658 (filter: 30_autogenerated): -> GETCONF DisableNetwork 10.152.152.11:53658 (filter: 30_autogenerated): <- 250 DisableNetwork=0 10.152.152.11:53658 (filter: 30_autogenerated): -> SETEVENTS STATUS_CLIENT 10.152.152.11:53658 (filter: 30_autogenerated): subscribed to event 'STATUS_CLIENT' 10.152.152.11:53658 (filter: 30_autogenerated): <- 250 OK 10.152.152.11:53658 (filter: 30_autogenerated): -> GETINFO status/circuit-established status/bootstrap-phase 10.152.152.11:53658 (filter: 30_autogenerated): <- (multi-line) 250-status/circuit-established=1 250-status/bootstrap-phase=NOTICE BOOTSTRAP PROGRESS=100 TAG=done SUMMARY="Done" 250 OK 10.152.152.11:53658 (filter: 30_autogenerated): -> ADD_ONION NEW:RSA1024 Port=9878,10.152.152.11:12345 10.152.152.11:53658 (filter: 30_autogenerated): <- (multi-line) 250-ServiceID=qnt5ga7x3ik3oucj 250-PrivateKey=RSA1024:**** 250 OK
Tibo (Tibo):
Tibo added a comment.
Oh, my bad...
Probably a manual config is required because otherwise localListenAddress is set to localhost. Manual config is not how it is supposed to work. It worked beforeYes exactly, and also to set the localListenPort.
That is also supposed to be automatic.
Whatever ricochet chooses should work due to EXTERNAL_OPEN_ALL=true.
So uwt / bindp does not have to set BIND_PORT.
Sorry if my question is stupid but, is there a reason to use bindp instead of
providing the configuration file ?
Usability. Much shorter and easier instructions.
"Just start the application" vs "follow all of this".
I notice that when i'm using bindp :
BIND_PORT=12345 BIND_ADDR="10.152.152.11" LD_PRELOAD=/usr/lib/libindp.so ricochet
(This is good for testing however later needs to be done by uwt.)
https://github.com/Whonix/uwt/blob/master/usr/lib/uwtwrapper did not use
BIND_PORT. So probably doesn't have to be invented.
What command uwtwrapper is actually executing to run bindp / ricochet?
Does that look sensible?
I think I misunderstood something.
I thought that the goal was to not use EXTERNAL_OPEN_ALL=true and just open one port on the workstation firewall.
I also thought that we could create the file $HOME/.local/share/Ricochet/ricochet.anondist-orig/ricochet.json with the config inside.
Exactly like the VLC config file I worked on.
So ricochet will be ready to use and the user will just have to open it.
Tibo (Tibo):
Tibo added a comment.
I think I misunderstood something.
Yes.
I thought that the goal was to not use EXTERNAL_OPEN_ALL=true and just open one
port on the workstation firewall.
How did you get that idea?
EXTERNAL_OPEN_ALL=true is uncool indeed but at least instructions are
simple.
This ticket is in status "needs review". Meaning, implementation is
done, but should be tested in next build.
This status is confusing and for ticket changes we'll be using
testing-in-next-build-required as status.
This ticket is in status "needs review". Meaning, implementation is
done, but should be tested in next build.
So the only remaining work here before you started working on this
ticket was:
Do the instructions in the wiki work as is? If yes, the ticket is done.
Sorry for the confusion!
I also thought that we can create the file
$HOME/.local/share/Ricochet/ricochet.anondist-orig/ricochet.json with the config
inside.
Exactly like the VLC config file I worked on.
So ricochet will be ready to use and the user will just have to open it.
I see.
However, then one still would have to modify Whonix-Gateway to create
the onion service. Resulting in ricochet in Whonix being more difficult
to set up than outside of Whonix. And very most users are deterred and
confused by a lot easier things already.
This ticket is in status "needs review". Meaning, implementation is
done, but should be tested in next build.This status is confusing and for ticket changes we'll be using
testing-in-next-build-required as status.This ticket is in status "needs review". Meaning, implementation is
done, but should be tested in next build.
So the only remaining work here before you started working on this
ticket was:
Do the instructions in the wiki work as is? If yes, the ticket is done.
Thank you for the explanation ! It's now much clearer.
I thought that the goal was to not use EXTERNAL_OPEN_ALL=true and just open one
port on the workstation firewall.How did you get that idea?
EXTERNAL_OPEN_ALL=true is uncool indeed but at least instructions are
simple.
I got this idea with :
Problem is, ricochet picks a random high local port so we actually have to open all incoming workstation ports. Posted a feature request upstream:
https://github.com/ricochet-im/ricochet/issues/30#issuecomment-271646818
It's also useful so users don't have to open all incoming ports in Whonix-Workstation firewall
But let's start with the beginning :
I followed the instructions in the wiki, and it's almost working.
The only thing missing is to set environment variable TOR_CONTROL_PORT=9151 and TOR_CONTROL_HOST="127.0.0.1".
That's all :).
Hm. Good catch.
Any idea why that is required?
- TOR_CONTROL_HOST="127.0.0.1": Shouldn't that be the default anyhow? Really doesn't work without it?
- TOR_CONTROL_PORT=9151: What does ricochet use by default? Port 9051? But that should work?
Could be a bug in anon-ws-disable-stacked-tor Tor emulation.
We used to set these variables.
But not anymore. Goals:
- stick with the defaults as much as possible to cause as little as breakage as possible
- maximum compatibility
- Tor emulation on Whonix-Workstation so most applications are working
- as few unneeded environment variables as possible
- not confuse Tor Browser with global environment variables (uses IPC and in future only IPC. Other environment variables could leak to some bug which makes it fail to connect in future.)
You think this can be fixed in anon-ws-disable-stacked-tor Tor emulation without setting a global environment variable?
Any idea why that is required?
Yes, ricochet is looking if a control port is defined in the config file or in the environment.
If a control port is defined, ricochet will not launch tor and will directly connect to the control host.
You think this can be fixed in anon-ws-disable-stacked-tor Tor emulation without setting a global environment variable?
Yes by creating the file etc/skel/.local/share/Ricochet/ricochet.anondist-orig/ricochet.json in anon-ws-disable-stacked-tor and specifying the control port inside it.
Another simple solution could be to edit the menu entry of ricochet to run it in a modified environment, which will not affect the global environment and not cause any breakage:
env TOR_CONTROL_PORT=9151 TOR_CONTROL_HOST="127.0.0.1" ricochet
At this point I don't know what is the best solution.
What do you think ?
Tibo (Tibo):
Tibo added a comment.
Any idea why that is required?Yes, ricochet is looking if a control port is defined in the config file or in
the environment.
If a control port is defined, ricochet will not launch tor and will directly
connect to the control host.
I see. So without these variables set, ricochet tries to to start its
own Tor client?
Is that startup prevented? (That is a goal of anon-ws-disable-stacked-tor.)
And if it fails to start its own Tor client, ricochet will terminate? Or
not try to use any connections?
I guess the upstream bug in ricochet here is: "ricochet ignores
...IPC... variables".
You think this can be fixed in anon-ws-disable-stacked-tor Tor emulation without setting a global environment variable?Yes by creating the file
etc/skel/.local/share/Ricochet/ricochet.anondist-orig/ricochet.json in
anon-ws-disable-stacked-tor and specifying the control port inside it.
(That would go into anon-apps-config package.)
I see. I want to avoid configs in home folders. These are a rabbit hole.
- works for new builds
- does not work for users who upgraded from earlier versions (unless we
invent a mechanism that might break)
- hard to update in future (distribution changes vs upstream config changes)
Another simple solution could be to edit the menu entry of ricochet to run it in
a modified environment, which will not affect the global environment and not
cause any breakage:
env TOR_CONTROL_PORT=9151 TOR_CONTROL_HOST="127.0.0.1" ricochet
https://github.com/Whonix/uwt/blob/master/usr/bin/ricochet.anondist
Add on top of export uwtwrapper_parent="${BASH_SOURCE[0]}"
TOR_CONTROL_PORT="9151" TOR_CONTROL_HOST="127.0.0.1" export TOR_CONTROL_PORT export TOR_CONTROL_HOST
I think that place would be better. Then we don't need to
config-package-dev displace another file and it also works from command
line.
(Working from start menu vs not working from command line would be
another strange bug that we would introduce by modifying the launcher.
Also then we'll easily miss out on upstream launcher code changes.)
I see. So without these variables set, ricochet tries to to start its
own Tor client?
Yes exactly !
Is that startup prevented? (That is a goal of anon-ws-disable-stacked-tor.)
Yes it is.
And if it fails to start its own Tor client, ricochet will terminate? Or
not try to use any connections?
Ricochet will print this error message and terminate :
Add on top of export uwtwrapper_parent="${BASH_SOURCE[0]}"
TOR_CONTROL_PORT="9151"
TOR_CONTROL_HOST="127.0.0.1"
export TOR_CONTROL_PORT
export TOR_CONTROL_HOST
I think that place would be better. Then we don't need to
config-package-dev displace another file and it also works from command
line.
Okay :), should I make a pull request ?
Sorry that it took so much for such a simply thing.
There are up to date Whonix 14 testers versions available.
- https://www.whonix.org/wiki/VirtualBox_Testers_Only_Version
- https://www.whonix.org/wiki/Qubes/Install/Testing
Could you test if ricochet works in these please? @Tibo