> [...]
>> In conclusion, I think the truth is that Whonix switching to our filter
>> will require some work to reach feature-parity with you current filter,
>> and you will not really gain anything by doing so except code sharing.
>> YMMV. That said, I'd happily implement match-hosts and the two
>> additional types of rules I mentioned above if that would be enough for you.
>
> I actually went ahead and implemented these, and I've successfully been
> able to run a client on a different host than the filter, like in
> Whonix. This is how I imagine the onionshare filter configuration Whonix
> needs would look like:
>
> - match-hosts:
> - '10.1.1.42'
> commands:
> GETINFO:
> - 'version'
> - 'onions/current'
> - pattern: 'net/listeners/socks'
> response: '250-net/listeners/socks="127.0.0.1:9150"'
> GETCONF:
> - '__owningcontrollerprocess'
> ADD_ONION:
> - pattern: 'NEW:BEST Port=80,(176\d\d)'
> replacement: 'NEW:BEST Port=80,10.137.6.41:{}'
> DEL_ONION:
> - '.+'
> events:
> SIGNAL:
> suppress: true
> CONF_CHANGED:
> suppress: true
> HS_DESC:
>
> If you need help deciphering the above I refer you to the "docs":
>
>
> http://git.tails.boum.org/tails/tree/config/chroot_local-includes/usr/local/lib/tor-controlport-filter?h=feature/7870-include_onionshare
>
> Thoughts about the configuration format are highly welcome (but I doubt
> I'd like to move away from YAML)!
Looks good!
> It would be interesting to see if this works for you in Whonix. You
> definitely will have to look at the --listen-address option (0.0.0.0 or
> the address the gateway connects to), and maybe the
> --control-cookie-path and --control-socket-path options (yes, the filter
> requires a cookie protected Tor ControlSoket for now -- patches welcome
> for other modes!).
Yes, no longer using ControlPort is a very good path. ControlSocket just
matches the defaults also in Whonix.
> I don't know if/how we should proceed, but here's what I think of the
> remaining (according to an earlier email in the thread) tickets you have
> for this in Whonix vs. our filter:
>> - https://phabricator.whonix.org/T562
>
> Solved!
>> - https://phabricator.whonix.org/T564
>
> I'd need more details of what the idea is here.
Prevent (in case of some bug or compromise) that more than X hidden
services are created. The number of hidden service should be tracked. If
more than X are created, requests for creating even more should be rejected.
This is because too many hidden services on the same connection may be
suspicious for ISP level adversaries or even dangerous for other tricky
anonymity reasons.
> Any way, it seems that if one is careful when writing the rules for
> ADD_ONION, one can limit the number simply by making sure there's that
> number of possible matches of [host:]ports. E.g. the above filter for
> onionshare can at most allow 100 ports. Solved?
I guess. Is that already possible?
>> - https://phabricator.whonix.org/T565
>
> I'd need more details of what the idea is here.
Have a script (or even unit test) that runs a loop, that creates a
zillion of hidden services. And then check if this has the chance to
make the whole system unusably slow. That would be considered ddos, and bad.
> ---
>
> Let me end with: if you test our filter in Whonix, and decide it's the
> way to go, then I'll try to do the Debian packaging unless someone wants
> to contribute it!
That's an awesome offer you! Yes, please do.
Cheers,
Patrick
