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 _______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.