IDS bells ringing
Chris Palmer
chris at eff.org
Wed Feb 1 03:33:02 UTC 2006
patgus wrote:
> For instance, a solution similar to hogwash
Incorporating an IDS into Tor (or just running one alongside Tor) has
been proposed before. Nothing can stop Tor server operators from running
an IDS on the Tor traffic.
But doing so has its problems, such as when the Tor exit policy is not
the same as that of the IDS (or firewall) the Tor server is subject to.
In that case, a server may be falsely advertising its capabilities, to
the detriment of the Tor network.
There is also this comment in the technical FAQ wiki:
http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#head-ebe87162a46f267eb697e23fb77e85e4cf643dd0
"Adding an Intrusion Detection System to handle exit policies would
increase the security complexity of Tor, and would likely not work
anyway, as evidenced by the entire field of IDS and counter-IDS papers.
Many potential abuse issues are resolved by the fact that Tor only
transports valid TCP streams (as opposed to arbitrary IP including
malformed packets and IP floods), so exit policies become even _more_
important as we become able to transport IP packets. We also need to
compactly describe exit policies in the Tor directory, so clients can
predict which nodes will allow their packets to exit -- and clients need
to predict all the packets they will want to send in a session before
picking their exit node!"
I have not read all the literature, but from what I've seen the entire
IDS field is close to being discredited. (I could be wrong.) Like spam
filtering, automated source code auditing and virus scanning, it's an
AI-hard problem. Now, that doesn't mean you can't get good results, but
it does mean you need to be a statistics genius with lots of free time,
patience, and a very closely specified task domain.
The cost of failure when applying such tools to transport and network
layer data is very high.
> At least then we could say that we were doing as much as is possible
> to prevent this and probably as much as any business in the industry.
I think we already are pretty close to doing as much as is reasonable.
Yes, it's *possible* to apply network, transport, content and other
layer filters, but it's not at all clear they're worth the cost,
complexity, and entertaining new failure modes.
Tor's exit policies in the hands of a responsible operator, together
with reasonable and polite negotiation, have been enough so far. At
least they have been in my experience.
> lol, most risks in the computer industry need to be litigated, not
> mitigated. 'Tis a bit of a situation though, how do you hold
> Microsoft responsible without crushing Debian?
And/or legislated, as the argument goes. This is also a highly
problematic proposition. Perhaps you could have some sort of vendor
liability law providing a cause of action for when software fails, but
with some kind of carve-out for FOSS software. That's a whole can of
worms I don't want to get into, but if you want to know some of the
potential problems, read up on anti-spyware legislation and proposals
for legislation.
More information about the tor-talk
mailing list