Fake Control Port

Development
1

A user perspective (there wasn’t a “cypherpunks” account already??):

I just found myself unpleasantly surprised to find out that anything running in the workstation had any access whatsoever to the Tor control port, even filtered access, and reading up on it led me to this thread.

If there’s a need to placate the Tor browser, I for one would prefer that you build a fake control port that lies about ALL commands and that never forwards ANYTHING to Tor, and I think that should run entirely on the workstation. Of course, that doesn’t mean that you should let the user believe that something like a “new circuit” button is actually working if it’s not, and I’m not sure how to ask you to go about preventing that false impression. Will it do something sane if you send back a failure code?

Any port on the gateway that the workstation can connect to is an exposure. There is no way that having a “new circuit” button inside the workstation is worth the risk of another listening port, and it’s SURE not worth the risk of sending “filtered” commands through to the actual Tor process. If I want a new circuit, I’ll do it in the gateway (I will admit that a nicer control program inside the gateway would be nice). That applies to ALL Tor control and status functions.

I use Whonix because I don’t trust the TBB, and I don’t trust the TBB exactly because of the willingness to open up infinite attack surface in the name of “usability”, and do crazy things like opening up sockets from the browser to the Tor control port. I do not want Mike Perry’s “usability” feature of the week.

The only reason the Tor browser should exist at all is fingerprinting resistance, because you HAVE to do that in the browser. But, because browsers are so ridiculously complex, it’s not trustworthy, and it shouldn’t be allowed to interfere with core isolation properties. If there’s no way to accommodate the Tor browser without giving it ever-increasing attack surface against the main anonymity system, then I suggest you just drop the Tor browser entirely.

Thanks for listening.

2

“Usability is a security feature.”

For disabling CPFP, we have instructions:

And in future, to ease that, hopefully whonixadvsetup will be implemented:
https://phabricator.whonix.org/T55

3

I completely agree with Patrick. Usability is very important. There is a simple reason why Email encryption failed on a large scale. Because it is at least one click more than without. It’s that simple. IF you need something more strict it is your prerogative to deactivate the proxy. It is very simple and documented.

The filter is very strict - IMHO too strict - I hope the discussion on this issue and the TBB progress will make the white listing more easy for the user as well. For me it would be very helpful If I could simply white-list the HiddenService commands, now I have to hack around it and open the Control Port or write my own proxy.

4

cpfp-bash is as well as cpfyp-py will be very easily configureable. You can just drop your snippets to extend existing white list. See also:

No hacking required.

But if you like to improve the code, please contribute. (Makes more sense to work on cpfyp-py.)

Not sure how this could be any easier? Do you mean was easy as a graphical user interface for it?

The issue with hidden services does not come from filtered vs unfiltered access to Tor’s ControlPort. These are missing features in Tor:

More info:

5

It is possible to hardcode the requests required for hidden services and to add a variable ALLOW_HIDDEN_SERVICES in cpfp.py (for what it’s worth until the issue in Tor is fixed).

Now, for ultimate usability, it is also possible to design a control port filter GUI to set all parameters (white list, disable fitering…) using .d style configuration. A task could be added in phabricator (long term).

6
ALLOW_HIDDEN_SERVICES
What would it do?

The problem is, the tool running in the workstation (onionshare or so) would try to access a file /var/lib/tor/hidden_service. But no such folder exists on the workstation. Whatever you let cpfp-py do, it cannot help fix this. It would require future trickery. As soon as cpfp-y notices the tool wanting to use that hidden service, it could relay the contents of that /var/lib/tor/hidden_service folder back to a special tool listening on the workstation which then creates that file. But that sounds quite complex and like a lot work to do. So much work, it might be better spend on learning C and implementing the missing features into Tor.

Now, for ultimate usability, it is also possible to design a control port filter GUI to set all parameters (white list, disable fitering...) using .d style configuration. A task could be added in phabricator (long term).
Kinda got somewhat such tickets already: - https://phabricator.whonix.org/T55 - https://phabricator.whonix.org/T89