anonym:
> Patrick Schleizer:
>>>> - 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.
>
> Ok, while the "other tricky anonymity reasons" may be true, I don't buy
> the ISP argument: in its position (it sees the first hop) the traffic
> generated by hosting lots of (never unused) hidden services won't look
> very interesting, I'd wager. If it looked interesting, an attacker that
> has compromised Whonix workstation would most likely be able to generate
> the same traffic pattern by using tor in some other way. Any way, I
> think a proper threat model where e.g. "suspicious traffic" is defined
> is needed to treat this properly. IMHO we have tons of much lower
> hanging fruit in the area of "network fingerprinting".
I agree with this.
>>> 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?
>
> Yes, e.g.:
>
> ADD_ONION:
> - pattern: 'NEW:BEST Port=80,(176[0-5][0-9])'
>
> That would match only the 50 different ports that onionshare will ever
> try to run the web server on. It's a solution by coincidence, but it
> works! :)
Ha, tricky, but a good solution.
>>> 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.
>
> Sorry, what I meant was: if you *first* try it (which should be easy in
> a running Whonix session) and decide that you want to use it, *then* I
> will do the packaging. Fair enough?
Sure. I was already testing the filter inside a running Whonix session. :)
So for using the Tails control port filter proxy in Whonix, there are
just two remaining blockers. The Debian packaging and the following...
Patrick Schleizer:
>> For connectivity, we need to remove 127.0.0.1 and replace it with
>> >> Whonix-Workstation IP. That is currently done with the following code
>> >> block that I was going to merge with T562.
>> >>
>> >>
https://github.com/Whonix/control-port-filter-python/blob/6a131266a8dc8f98ff22a3b83fae9d43e38b3127/usr/sbin/cpfpd#L345-L375
>>
>> Got it. Our filter doesn't do this (as we do not have this need) but I
>> feel a general solution could be to allow sed-like rewriting rules, e.g.
>>
>> ADD_ONION:
>> - pattern: 'NEW:BEST Port=80,(176\d\d)'
>> replacement: 'NEW:BEST Port=80,10.137.6.41:{0}'
>>
>> which would be easy to implement.
Where I need to correct myself. The injected IP is probably difficult to
add to a config file since IPs in Qubes will remain dynamic for some
quite some time until Qubes 4.0. We'd need something like this.
ADD_ONION:
- pattern: 'NEW:BEST Port=80,(176[0-5][0-9])'
replacement: 'NEW:BEST Port=80,<client i.e. workstation IP>:{}'
(Where <workstation IP> is just used to illustrate. Not a syntax
suggestion. Could be expressed with any other special chars.)
Could you implement that please?
Cheers,
Patrick
