Whonix compatibility & integration #30
Comments
|
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 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:
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.
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.
Without a control connection, the user would have to manually configure a hidden service in their |
|
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. |
|
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:
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. |
Allowed by default.
Allowed by default.
Allowed by default, but... It currently is a fake answer / lie:
Instructions how to whitelist those have been created: Haven't looked at security implications of these yet.
This is a real problem.
Can you implement the missing features into Tor? |
|
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.
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.
Cool.
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. |
|
@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:
Please consider having Torsion work in a similar way in the event that its started with a special transparent-proxy option . Reference: |
|
@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. |
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. |
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.
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. |
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. |
|
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. |
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.
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. |
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. |
|
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. |
|
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. |
You might be interested in this...
|
|
Has there been any recent progress with this? |
|
rodneyrod:
Yes, but it's not done. Missing feature: Help welcome. Instructions work in progress: (Ignore that these instructions are for onionshare. Ricochet can be |
|
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. 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
An option to listen on other interfaces than localhost would be useful for Whonix. Now using 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 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 |
|
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 |
special
changed the title
…debian-build Debian packaging, manpage, fixed static build
issue_27: fixed app icon display on Linux
Whonix is Debian based and its gateway VM would be need to setup to run the hidden service while the workstation VM runs the UI and backend that directs its connected to the gateway where the Tor client is running.
Example on how TorChat is setup in Whonix: http://zo7fksnun4b4v4jv.onion/wiki/Chat#TorChat
The text was updated successfully, but these errors were encountered: