[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: IDS bells ringing

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:


"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.