In December 2019 I wrote about The Growing Problem of Malicious Relays on the Tor Network with the motivation to rise awareness and to improve the situation over time. Unfortunately instead of improving, things have become even worse, specifically when it comes to malicious Tor exit relay activity.
Tor exit relays are the last hop in the chain of 3 relays and the only type of relay that gets to see the connection to the actual destination chosen by the Tor Browser user. The used protocol (i.e. http vs. …
Since there have been some speculations and questions around why all of a sudden I disappeared from twitter I’d figure I give you with my side of the story.
TLDR: I don’t know why my account got suspended and my appeal was turned down.
Initially I created my twitter account in February 2016 but since it required a phone number verification I was not able to actually use it until a year later when someone made a small donation for my first medium blog post that allowed me to pay for an online SMS service to pass the twitter phone…
I’ve a long standing interest in the state of the Tor network. In 2015 I started OrNetRadar to help detect new relay groups and possible Sybil attacks that could pose a risk to Tor users. In 2017 I was asked to join a closed Tor Project mailing list to help confirming reports of malicious Tor relays — a list where I previously submitted suspicious relays to. Soon after joining that list I suggested some improvements but things didn’t change since then. …
Over a year ago, in April 2018, we looked into Tor’s DNS landscape and confirmed previous observations from 2016 that a significant fraction of tor exit relays make use of public DNS resolvers like Google’s 220.127.116.11.
Now 15 months later, its time to revisit this issue again to find out in what way the DNS landscape on the tor network changed. Did the DNS centralization on the tor network around Google and Cloudflare resolvers increase or decrease?
The methodology remained largely the same, we built a circuit to every tor exit relay to resolve a hostname while watching the source…
Mapping the RPKI unreachable IP address space.
In the previous post (see that for some more context) we analyzed RPKI INVALID IP address prefixes that are unreachable (no alternative route available) and used number of prefixes-origin pairs as primary metric, but argued that prefix-origin-pair-counts are not the best metric (many small prefixes can distort the picture) and left the task of analyzing unreachable networks by IP address space for the future:
add analysis based on IP space size (not just prefix-origin pair counts)
So this time, instead of using number of prefixes, we take the actual prefix size…
Up until not too long ago basically no network operator actually protected herself by implementing route origin validation (ROV) to make BGP hijacking attacks harder.
Implementing ROV means that BGP prefix-origin pairs are validated against route origin authorizations (ROAs) before they are considered. An autonomous system (AS) performing ROV is less vulnerable to BGP hijacking than an AS not doing so.
Example of a ROA: The following ROA authorizes the AS13335 to announce the prefix 18.104.22.168/24 (other ASes are not authorized to announce 22.214.171.124/24 and their prefix would be flagged as INVALID if they were to announce it):
Privacy adversaries may use BGP hijacking attacks to gain access to a bigger portion of Tor traffic than they would be able to see otherwise. BGP hijacking can be used to reroute internet traffic (for traffic interception and correlation attacks) or to perform denial of service against specific relays to increase the chance that Tor users select attacker-controlled relays.
The RAPTOR and Counter-RAPTOR papers by Sun et al. studied the effect of BGP attacks on Tor, in their paper they note:
more than 90% of BGP prefixes hosting Tor relays have prefix length shorter than /24, making them vulnerable to…
Unlike other relays, tor exit relays also take care of name resolution for tor clients. Their DNS configuration actually determines where the tor network’s DNS traffic is send to.
Ever since the tor-dns paper I wanted to take a look at the current state of DNS resolver distributions on the tor network. In their work from 2016 they noted that Google controls a significant share of tor’s DNS traffic.
Here is a plot of their data from 2015-2016 showing Google as the DNS resolver controlling the biggest chunk of the tor network’s DNS traffic:
A limited number of relay groups can see you enter and exit the Tor network (deanonymization).
TL;DR: If you want to get the list of relevant Tor relays go to the bold URL near the end of this page.
When a Tor client routes traffic through the Tor network he tries to select 3 “random” (mostly) relays (guard, middle and an exit relay). The number of relays is crucial. Using 3 hops should help reduce the risk that a single entity (excluding global passive adversaries) can “see” Alice’s real IP address and the fact that she is talking to Bob…
On 2017–03–06 and the day following that, a significant number (57) of tor relays joined the network, they all share the nickname prefix “UbuntuCore”.
In March 2017 over 290 such relays joined the tor network. This sparked my interest.
TLDR: As a tor user, you do not need to worry about them (yet), because they only make up a tiny part of the tor network (current total consensus weight fraction: <0.05%).
Update: As an example, this “UbuntuCore” relay group is about ten times smaller (by consensus weight fraction) than the (currently) biggest group of relays that you — as a…