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".
>> 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! :)
>>> - 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.
onionshare (with and without the filter) is limited to 50 of them at the
same time, so this does not seem like a concern for now. Just for kicks
and giggles I tried running
for i in $(seq 1 100); do echo $i > $i; onionshare $i & done
but this just exposed that onionshare's method of picking a free local
port is extremely prone to a race condition (many instances picking the
same port) so the results are not very relevant.
>> 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?
Cheers!
