Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That's not necessary. Most of the relays in the report were already BadExited by the Tor Project. That means that the network consensus has the "BadExit" flag set which tells Tor clients not to select a particular relay as the last hop in its circuit. In fact, by interfering with your path selection algorithm, you reduce your anonymity over time.


First thing I did is to check the directory, there are 6 nodes that i've checked so far (starting from the bottom) that are still listed :

http://82.94.251.203/tor/status-vote/current/consensus

I see no problem with running this automated test and adding these nodes yourself once you find them since BadExiting is a non-transparent process that appears to have delays in it.

edit: as an aside, using country codes as I listed "ExitNodes {us}" is nothing more than an example to express the syntax options.

It is good to know incase you need to get a particular exit point for geo-restrictions, etc. and your adversary isn't the NSA.


Could you elaborate on why manually blocking known bad exits is worse for anonymity than letting the network decide this?


Manually blocking known bad exits won't really hurt your anonymity but it's also not really necessary as the Tor Project does that for you.

I was actually objecting to stuff like this: ExitNodes {us}. By interfering with your path selection algorithm in such a strong way, you make it easier for attackers to narrow down your path over time (which gives them an idea of which exit relays to monitor) and intersection attacks also become easier. Then again, you might have good reasons to do exactly that. It depends on your threat model, of course.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: