Whonix compatibility & integration about ricochet HOT 22 OPEN

At the moment, this is a design that we wouldn't work well with. That is a shame, and it's worth thinking about.

Torsion currently requires that it has a control connection with the tor instance. I'll go into detail below on why that is and why I'm not eager to change it. It would be relatively easy to add options that would allow Torsion to function now without a control connection, but I worry about future expansion.

Thoughts on this topic would be welcome; there's not an easy solution. Ideally, it would be possible to control and publish hidden services without exposing other control over tor's operation. That is a very niche request that would require significant upstream work, though.

The control connection is used:

• To monitor the online/connectivity state for the UI

The UI indicates whether tor is online and able to build circuits, which distinguishes "all of your contacts are offline" from "you are offline". That is important, but it's not critical.

• To monitor online state for reconnection behavior

The connection attempt logic also considers online state: connection attempt intervals start small after coming back online, and quickly scale up. If there was no knowledge of online status, those intervals would have to always be shorter to have relatively quick reconnection.

• To manage publishing a hidden service

Without a control connection, the user would have to manually configure a hidden service in their tor instance. This is not an easy process. More importantly, putting this in the user's hands would cripple future improvements: it wouldn't be possible to manage multiple hidden services, toggling the online state of services, or client authorizations if the software can't directly control tor. I'm worried about giving up those options, because I think some of them have great potential for improving privacy/security.

from ricochet.

Most likely this is possible. Modding friendliness was always a priority and this pays off in situations like this.

Can you make a list of control port commands that are sent to Tor please?

Without having ever had torsion installed, I can say... torsion could most likely normally access Tor's control on Whonix-Workstation on 127.0.0.1:9051 or 9151. This is because rinetd is listening on these ports and forwarding this to Control Port Filter Proxy listening on Whonix-Gateway. Probably no change in torsion required here.

Control Port Filter Proxy support modular, flexible configuration snippets. (default config) Once you made a list of required control port commands, I am happy to write the configuration snippet required. Only the CONTROL_PORT_FILTER_WHITELIST variable needs to be extended a bit. This is easy for me, a matter of a few minutes.

Once there is a list of control port commands, we can also discuss how much security would be lost by this change. I am happy to host documentation in whonix.org wiki and/or here. As long as it's clearly documented, the user is free to decide to use or not use torsion with Whonix.

from ricochet.

Great! I wasn't aware of the Control Port Filter Proxy; that's a very useful solution.

The current list of commands, excluding things relevant only to bundled Tor, is:

• AUTHENTICATE
• GETINFO status/circuit-established status/bootstrap-phase net/listeners/socks
• SETCONF HiddenServiceDir HiddenServicePort
• SETEVENTS STATUS_CLIENT

The bigger problem is that the hidden service files must be readable by Torsion; it needs access to the private key and (in the future) client authorization files. Some of the work under https://trac.torproject.org/projects/tor/ticket/8993 is relevant here; the ideal case would be that https://trac.torproject.org/projects/tor/ticket/1949 is implemented and Torsion is able to manage these files itself.

from ricochet.

AUTHENTICATE

Allowed by default.

GETINFO status/bootstrap-phase

Allowed by default.

GETINFO net/listeners/socks

Allowed by default, but... It currently is a fake answer / lie: 250-net/listeners/socks="127.0.0.1:9150". Does this matter? For next Whonix version I just implemented a feature to disable this and give a real answer. One could just get the updated file and overwrite /usr/lib/whonix/cpf-tcpserver if this is required. What kind of answer would torsion be happy with here? If all cords break, implementing another fake answer / lie would be simple, I'd be happy to sort this out one way or another.

GETINFO status/circuit-established
SETCONF HiddenServiceDir
SETCONF HiddenServicePort
SETEVENTS STATUS_CLIENT

Instructions how to whitelist those have been created:
https://www.whonix.org/wiki/Next#torsion

Haven't looked at security implications of these yet.

The bigger problem is that the hidden service files must be readable by Torsion; it needs access to the private key and (in the future) client authorization files.

This is a real problem.

Some of the work under https://trac.torproject.org/projects/tor/ticket/8993 is relevant here; the ideal case would be that https://trac.torproject.org/projects/tor/ticket/1949 is implemented and Torsion is able to manage these files itself.

Can you implement the missing features into Tor?

from ricochet.

A few small changes are necessary to allow running without a bundled instance. The UI doesn't handle that case yet, because this is the first situation [so far] where it makes sense.

It currently is a fake answer / lie: 250-net/listeners/socks="127.0.0.1:9150". Does this matter?

Not really; it will use this as the socks address if one isn't configured separately. All it expects is an address and port it can connect to.

Instructions how to whitelist those have been created:
https://www.whonix.org/wiki/Next#torsion

Cool.

Can you implement the missing features into Tor?

It looks like someone had started at https://trac.torproject.org/projects/tor/ticket/6411, but abandoned the effort. It's also a slightly flawed solution.

I'm interested in implementing them to allow better protection of the private key anyway, but it's subject to limits on my free time. I'll try to look into at least writing the specification I'd want and getting review on that. Any help would be appreciated.

from ricochet.

@special Hi I recently discussed removing the ControlPort dependency entirely from software that uses Tor such as TBB and Onionshare because a ControlPort filter is not robust enough to provide the kind of separation needed between the virtual machine that runs Tor and the untrusted workstation, in our threat model. Adversaries with powerful capabilities could make the filter parse malicious input that could fool it into doing something harmful and unintended.

My suggestion has been taken positively by Micah and TBB developers to allow their software to not use Tor ControlPort as a hard dependency. The way Onionshare is planned to work, is something like this:

Maybe there could be an extra flag, like onionshare-gui --transparent-proxy that adds port and .onion fields to the GUI for you to fill in, and leaves the task of starting the HS to you.

Please consider having Torsion work in a similar way in the event that its started with a special transparent-proxy option .

Reference:
onionshare/onionshare#139

from ricochet.

@HulaHoopWhonix I'm hesitant to commit to supporting that right now. I outlined the reasons we use the control port in this comment. I want to avoid prematurely tying our hands on features that might require direct interaction with Tor.

But, I realize it is important for those kinds of systems. The control port filter is my preference, but if it becomes necessary we can try to work out a way to live without it and not hurt the UX too much.

from ricochet.

But, I realize it is important for those kinds of systems. The control port filter is my preference, but if it becomes necessary we can try to work out a way to live without it and not hurt the UX too much.

Yes please do. I would really like to use your software in Whonix without making any security tradeoffs.

from ricochet.

Yes please do. I would really like to use your software in Whonix without making any security tradeoffs.

Allowing this is a usability tradeoff. If we follow my theory that usability == security, we're just trading security for a different kind of security.

I will have to change the reconnection behavior on these systems, which causes more traffic and is something the peer/network could detect. If the user is running their system Tor but isn't running Ricochet, their service will be published but will fail connections - something the peer can detect. I may have to disable important features for these systems, because it won't be possible to control publication of a hidden service. If circumstances change later, I may be forced to choose between crippling these users or crippling all users.

Setup for these systems will be harder, and platform specific. It'll require specialized scripts and tools, or a very technical user. The outer, Tor-running system would store extremely sensitive data (private keys).

It is not a clear case that users are made more secure by not having a control port. It might even be better for them to run Tor-over-Tor than suffer all of the above, if they have no other choice. I don't think a well written control port filter is a bigger risk.

from ricochet.

I will have to change the reconnection behavior on these systems, which causes more traffic and is something the peer/network could detect. If the user is running their system Tor but isn't running Ricochet, their service will be published but will fail connections - something the peer can detect. I may have to disable important features for these systems, because it won't be possible to control publication of a hidden service. If circumstances change later, I may be forced to choose between crippling these users or crippling all users.

No, I am not suggesting you tailor your entire program just for our usecase. In onionshare its implemented as a option flag that makes it behave in a different way to allow users to tell it about the Hidden service configured on the gateway, rather than it setting it up on its own.

It is not a clear case that users are made more secure by not having a control port. It might even be better for them to run Tor-over-Tor than suffer all of the above, if they have no other choice. I don't think a well written control port filter is a bigger risk.

Tor's control port has at least one, in context of Whonix, dangerous feature. Its "GETINFO address" and the answer to this request will be the real external IP of the Tor client. The filter's security in our threat model is questionable, as bash is not intended to parse malicious input.

Let's just agree that it might it might require a lot of effort for you to change you program to work behind a transparent proxy, but the reasons for not allowing communication with the controlport is a valid concern.

from ricochet.

No, I am not suggesting you tailor your entire program just for our usecase. In onionshare its implemented as a option flag that makes it behave in a different way to allow users to tell it about the Hidden service configured on the gateway, rather than it setting it up on its own.

In Ricochet, it's not so simple: we use (and intend to use) the control port for more than just one-time setup of a hidden service. Operating without it requires a substantial and ongoing set of changes, workarounds, and inconvenience to the user. Those changes could reduce security, too.

My suggestion for Whonix and similar systems is to run Ricochet normally, with its own instance of tor, and pass that through your system/network-level tor instance. Running tor over tor isn't great, but it's the best answer available now.

If someone wants to use a control port filter later on, we can explore the other challenges with that solution.

Can someone try running Ricochet with that tor-over-tor approach on Whonix and document how it goes? I hope it will be simple.

from ricochet.

Tor-over-tor is discouraged by upstream because of unclear implications for a user's security. They are also planning to prevent this from being allowed because of bandwidth amplification attacks that could oveload and potentially destroy the Tor network.

from ricochet.

Tor-over-tor is discouraged by upstream because of unclear implications for a user's security.

Correction: unclear implications for a user's anonymity.

Tor-over-tor is discouraged by that upstream; control port access is discouraged by you; manual publishing through a system-level tor (and not having tor's events) is discouraged by me. We have to compromise somewhere, and I think tor-over-tor is the best option at the moment. The worst case effect on anonymity is not so severe, since it still rests on the system-level tor's guard.

They are also planning to prevent this from being allowed because of bandwidth amplification attacks that could oveload and potentially destroy the Tor network.

As far as I know, there aren't any imminent plans to change this. Do you know of anything?

from ricochet.

As far as I know, there aren't any imminent plans to change this. Do you know of anything?

Its a trac ticket I read quite recently. It is going to happen not really hear-say on my part. Its not going to last as a workaround no matter how good it seems right now.

from ricochet.

Its a trac ticket I read quite recently. It is going to happen not really hear-say on my part. Its not going to last as a workaround no matter how good it seems right now.

I found ticket 2667. It is 4 years old, last modified 2 months ago, and doesn't seem to have a consensus on how to solve the problem.

I'm not going to make the changes we'd need to work without a control port, at least until we know more about the future direction of the design. If safe control port access becomes possible later on, we can try to figure out the other problems with that approach (such as hidden service files). For now, tor-over-tor is the only option.

from ricochet.

It won't really change your calculus for the workaround you suggested, but this CVE published today shows exactly the kind of security holes in ControlPort filtering I was talking about. Its no longer theory.

https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/

from ricochet.

Tor 0.2.7.x should be adding a control port API for publishing hidden services without using the filesystem. With that and the control port filter, it should become possible for Ricochet to use the whonix Tor instance (with a bit of port forwarding glue, probably).

You might also be interested in https://github.com/Yawning/or-ctl-filter - this is a probably-more-secure control port filter written in Go, instead of bash.

See https://bugs.torproject.org/6411

from ricochet.

You might also be interested in https://github.com/Yawning/or-ctl-filter - this is a probably-more-secure control port filter written in Go, instead of bash.

You might be interested in this...

• [Tails-dev] Announcing control-port-filter-python - a fork of tor-controlport-filter by Tails: https://mailman.boum.org/pipermail/tails-dev/2015-March/008388.html
• https://github.com/Whonix/control-port-filter-python

from ricochet.

Has there been any recent progress with this?

from ricochet.

rodneyrod:

Has there been any recent progress with this?

Yes, but it's not done.

Missing feature:
support for Tor control protocol events (setevent) by Control Port
Filter Proxy
https://phabricator.whonix.org/T448

Help welcome.

Instructions work in progress:
https://www.whonix.org/wiki/Next#onionshare

(Ignore that these instructions are for onionshare. Ricochet can be
found below, and instructions would be very, very similar.)

from ricochet.

On the Whonix side lots of progress has been made.

onionshare (in the widest sense) is similar to ricochet. Both are using ephemeral Tor hidden services and listen on localhost.

onionshare works in development version of Whonix. All issues so far have been worked around. Whonix now uses almost the same code for control port filtering as Tails. (control-port-filter-python)

ricochet should be doable also.

• Whonix ricochet ticket
• ricochet control port filter whitelist config

As for ricochet:

Could you add a feature please for ricochet to only listen on a specified range of local ports? I don't mean Tor VIRTPROT. That does not matter. But the real local port the Tor opens matters.

onionshare uses 17600 - 17659. That is handy, so we can match for it using (176[0-5][0-9]) in the onionshare control port filter whitelist config.

• That way onionshare (running inside a compromised workstation) cannot open arbitrary ports on the workstation. For example, not to the real Tor ControlPort and circumvent the filtering. (We use Tor ControlSocket rather than ControlPort now for this reason.) There are no local ports open on Whonix-Gateway besides Tor Socks, DNS and TransPort, but if there was (let's say for example for brltty, then we don't want connections to it.
• That allows us to set a limit on how many Tor hidden services (a compromised) workstation can create.
• It's also useful so users don't have to open all incoming ports in Whonix-Workstation firewall.

An option to listen on other interfaces than localhost would be useful for Whonix. Now using bindp as a workaround. (Details, commit here: https://phabricator.whonix.org/T561)

However, the clean solution would be if ricochet would automatically listen on interface eth0 rather than 127.0.0.1 once Whonix is detected. (Check for existence of file /usr/share/anon-ws-base-files/workstation.)

And if auto detection sounds too scary / Whonix specific, then it would be good if the listen interface could be expresses as a drop-in configuration file in /etc/ricochet.d/, we would then drop a snippet /etc/ricochet.d/40_whonix.conf.

from ricochet.

Thanks for the followup! See #512 for some thoughts on those two requests. If you have strong feelings about where those options should be configured, feel free to mention it there. I would prefer having system-level default config files over hardcoding anything.

The settings to control the local bind address and port actually already exist -- just not in a way that is useful for platform-level configuration. If you want to prototype now, you can set identity.localListenAddress and identity.localListenPort in the ricochet.json file after it's created.

from ricochet.