One point that folks should not forget is that it was never a silver bullet option, even the original paper said it was not designed to protect against a global passive adversary.
To quote it directly:
“3.1 Threat Model
A global passive adversary is the most commonly assumed
threat when analyzing theoretical anonymity designs. But
like all practical low-latency systems, Tor does not protect
against such a strong adversary.”
The only thing you could really use to defend against that would be like a high latency mix network to throw off the timing, but that would be unusable for modern browsing. The whole reason why tor went with a low latency design is that it could be usable for a wide array of activities instead of things where time doesn’t matter that much, like email or file transfers.
So in case of global adversaries, its not like Tor is ignoring them, its just a design choice to balance usability/flexibility of the network and its anonymity properties. That some people just assume Tor is the end all be all of anonymity which should protect against everything is on them for not doing their research, not on the Tor project.
The “counter-Raptor” paper (and by extension, the Raptor one before it) makes some concerning claims that have not been addressed neither by the TOR project, nor here:
“The paper also showed that these routing attacks have occurred on the Tor network. Using past BGP data, they demonstrated that Tor relays were affected in prefix hijack attacks. For example, in the Indosat hijack in 2014 [17], among the victim prefixes there were 44 Tor relays, and 33 of them were guard relays which had direct connections with Tor clients.“
And also that:
“[8] show that deanonymization accuracy can reach 90% by performing a longest-prefix attack for less than 5 minutes. “
All of this is with regards to active attacks that have previously been carried out against the Tor network.
I admit to having very little knowledge PR understanding of the subject, but there has been no sufficiently satisfying answer as to why this issue has not been addressed.
Could you link to the papers you are mentioning here for completion sake. Its makes for a nicer converdations when folks following the thread do not have to hunt down papers
I’m not sure what Tor thinks about this, but I don’t really view the Counter-RAPTOR plans as a complete solution to this issue personally.
We are talking about an attack that takes place before you even hit the Tor network, so the extent of what Tor can do to mitigate it is limited. The Counter-RAPTOR proposal essentially calculates a “resiliency” metric for each guard node based on properties of their ISP, and then has clients prioritize guard nodes based on that metric.
This creates two problems:
Malicious ISPs running their own guard nodes can much more easily game this system, compared to gaming the system now. At the moment to get higher priority you basically have to offer more bandwidth, which does have an actual cost. If you can get a higher priority just by adjusting your BGP settings that will be cheaper.
Guard nodes learn more about clients connecting to them. There is a fingerprinting problem here if a client’s guard selection choices can be observed over a long enough period of time, you might be able to derive some information about the client’s own ASN based on the choices it makes during selection.
Counter-RAPTOR’s best proposal against these two problems is introducing randomization in the selection process, which obviously means it is not even a complete solution, because you could randomly select a “less resilient” guard node. So, all it is really doing is decreasing the probability of an attack, and likely not by enough to warrant adding all of this additional complexity to the Tor client. Additional complexity can extremely easily translate into future fingerprinting/anonymity issues that nobody has even considered yet.
The proper solution to this problem is RPKI, which is already being implemented by many ISPs today, plus ASPAs, which I hope ISPs finally get around to doing sometime this century.
You can test your ISP here and if it passes then your risk of this attack is highly reduced already (not eliminated because BGP is ass, especially without ASPAs), without Tor having to do anything: https://isbgpsafeyet.com/
I just remembered Mental Outlaw is this guy, so he is clearly just out of his depth when he is talking about Tor and networking. He seems like a cool guy and I’m sure he means well, but it’s just like that other YouTuber who was talking about Tor in a post on here a month or two ago: Just because you have an opinion about something, like BGP attacks or OS fingerprinting, doesn’t make you an expert on that thing
If I understand correctly, the resiliency metric is based on BGP topography rather than “settings” - it is dependent on the relationships between networks, and is relative for each client. If I’m correct, this means that it would not be practical or cheap for an ISP to re-route all its connections specifically for the purpose of exposing a single tor node (from what I gather, BGP is a nightmare to setup or change).
Secondly, with regards to the concern about identifying a clients ASN, I’m not sure that anti-Raptor would change anything. The paper cites a previous work concluding that, at present, AS choice is determined by proximity (customer route is preferred over peer route, which is preferred over provider route) and bandwidth. This means that even now, there is some information allowing the identification of the clients ASN. While resiliency is client-specific too, randomization is intended to mitigate both its and the existing local preference’s potential to de-anonymize clients.
All in all, I agree that the issue is fundamentally with BGP, and not the Tor network, but if there is a mechanism to mitigate the risk of attacks that are known to have occurred, it seems irresponsible to not have implemented it for so long.
A lot of people use Tor browser for its anti-fingerprinting feature, not to protect against potential leaks which Whonix should’ve been used if that’s the case and not Tails as many exploits were found where it leaked before.
I just remembered Mental Outlaw is this guy, so he is clearly just out of his depth when he is talking about Tor and networking.
I haven’t watched his content for some time, but all I know is he used to work for Geek Squad and now lives somewhere in the countryside with chickens.
Now he is showing how to turn LibreWolf into a Tor Browser replacement. He proceeds to uninstall uBlock Origin because “sites can use it to fingerprint you”, and installs NoScript so LibreWolf looks like Tor Browser. He also changed the user agent to look like Windows because he still thinks the decision made by the Tor Project was wrong. He says at the beginning that this is not approved by the Tor Project, but why even spread this “information”?
Really disappointed in him for doing this, because someone will end up doing it since they don’t know any better, regardless of the disclaimer he makes in the video.
Librewolf is literally just Firefox with a few configurations. Why is he so worked up over the http user agent to reach this point.
Imagine sacrificing the hardening and anti-fingerprinting features of Tor Browser just to score very minor points in anonymity (which can be easily bypassed btw)
It also seems a bit irrational and futile to worry about this:
He proceeds to uninstall uBlock Origin because “sites can use it to fingerprint you”,
…in the context of this:
turn LibreWolf into a Tor Browser replacement […] changed the user agent to look like Windows
It seems like he is effectively placing himself in a crowd of 1, and then turning around and worrying that uBO will make him stand out from that crowd of 1…
It also seems pretty ill-advised to use a browser (for anything remotely mission critical) who’s own maintainers characterize the current status of the project as being ‘basically in maintenance mode’ [1] and lacking both adequate time/manpower and deep expertise in security or anonymity [2]
edit: looks like the links didn’t work in the footnotes here are the srcs #1, #2
As threadpanic said, since fxbrit left we have been in a kind of “maintenance” mode in terms of settings. Mainly because we are really only three people left, who all only have varying time to put into the project (src) ↩︎
Hey all, I’m on the LibreWolf team, and it’s t@fxbritue that since t@fxbrite de@fxbritarture of @fxbrit the project has taken a total nosedive when it comes to keeping up to date with Arkenfox and settings in general… I’m mostly a c/rust/vulkan hobby person, not at all good with Browser Security. My first impression is that it’s a total mine field (src) ↩︎
