On 11 Mar 2015 06:12, <firstname.lastname@example.org> wrote:
>> For example, I have a VM running an MUA, it should only ever connect to
>> it's mailserver's over Tor. To enforce that, my router runs Tor and an
>> iptables rule ensures that all traffic from that VM leaves my network over
>> Tor (there are some other concerns with doing it this way, but they aren't
>> relevant for what I'm trying to say).
> Can you expand on this, the Tor on a router part? Others have said, in response to an out of the box product you can by, that running Tor on a physical router is not so safe, though this is maybe where your iptables rule comes in.
The advice given in that thread is correct - but it relates primarily to Web browsing, and makes a few assumptions about user behaviour (wise assumptions IMO though).
For the setup I described above, the traffic being carried is SMTP/IMAP so I don't need to worry about tokens being exposed in quite the same way. I can also guarantee that traffic from that VM will never leave my network over anything but Tor (the edge firewall will drop it's traffic).
In theory, you could use an edge firewall to afford similar protection for web browsing, though it would still leave a few risks, even assuming the access device you were using was something that was only ever on that network (i.e. a desktop not a laptop).
Similarly, if you were doing it all in one box (i.e. browser and Tor client are all on the same system) you could, potentially achieve a similar fail-safe environment, but it's by no means guaranteed.
Pushing to Tor at the network level helps against things like badly behaved plugins that ignore proxy settings (though you shouldn't really be using them anyway), but does carry it's own set of risks, some of which are well described in that thread.
Because no specific config is needed at the browser, it allows you to use your 'everyday' browser, so the cookies you pick up whilst browsing will be sometimes be sent in the clear, and sometimes over Tor - that's obviously problematic.
Also, depending on your config, anything running on your machine will also be routed over Tor. If any of those send credentials that can be tied back to you (e.g. credentials for a backup server in your name) then you've got issues.
You _could_ try to work around it by selectively routing over Tor, but then you've just opened a nice wide vector for information leakage.
With my mail VM, I have specific ports and destination IPs that it can talk to. Everything else is denied, so it should be fairly safe, but it is inherently inflexible.
>> There's no technical reason I (or, you) couldn't add a rule to first push
>> that traffic through some sort of (semi)transparent proxy so that filtering
>> can be performed at application level.
> How much control do you then have over the traffic? Can you shape how you appear, ignoring the risk of standing out? How would you interface with the traffic?
It'd obviously depend on exactly what you were wanting to do, but as a basic example, you could for example push HTTP traffic through a Squid install first so that you can perform specific actions based on the HOST header, or perhaps the content-type in the response (perhaps to block ads?).
If you're talking about doing it for an entire network, it'd also allow you to cache specific resources.
All of the above could make your traffic stand out, of course, but it's technically feasible. In effect, what you'd be doing is creating a proxy on the network (transparent or otherwise) and configuring it to use Tor for its upstream connection (though if you're doing it at the firewall level, Squid would never see such a config).
>> But I am more asking if Tor can be used as part of a filter, with some
>> sort of application allowing for more control, maybe even of what is sent
>> to the entry.
You could achieve that with what I described above, whether or not it's a good idea would depend largely on why you're using Tor - what are the consequences if you make a mistake in the setup? If you're simply trying to prevent your ISP from seeing where you're connecting to, it's potentially less risky than if your activities might cause LEA(s) to kick down your door.
Using TBB with it's default settings is a fairly simplistic configuration, and thanks to the developers behind it, there's not too much that should go wrong on the average deployment.
Every additional step you insert introduces an opportunity for you to make mistakes (even if that's as simple a not thinking of a specific type of traffic), so you need to carefully design your setup and do a cost/benefit on the changes.
I experiment with Tor quite a lot, and, on the average day a good proportion of the traffic leaving my network via Tor is probably me testing something 'harmless' to see if I can catch myself out. Once I'm happy that a technique works, it'll get used for something I'm more sensitive about.
One thing I would say - you have to consider failure scenarios very carefully. If Tor silently fails on your router, what will happen with new connections? Will they fail (you probably want this) or will they be routed out in the clear (leaving you non-the-wiser).
All that said - If I was doing something really sensitive, or with serious real world implications, I'd be using the simplest solution possible (i.e. TBB) to minimise the potential for mistakes on my part.