Towards a more Trustworthy Tor Network

intro music

Herald: This is now
"Towards a more trustworthy Tor network"

by Nusenu

The talk will give examples of malicious
relay groups and current issues and how to

tackle those to empower Tor users for
self-defense, so they don't necessarily

need to rely on the detection and removal
of those groups.

So without further ado, enjoy!

And we will see each other
for Q&A afterwards.

Nusenu: Thanks for inviting me to give a
talk about something I deeply care about:

The Tor network.

The Tor network
is a crucial privacy infrastructure,

without which,
we could not use Tor Browser.

I like to uncover malicious Tor relays
to help protect Tor users.

But since that does not come without
personal risks, I'm taking steps

to protect myself from those
running those malicious nodes,

so I can continue to fight them.

For this reason, this is a prerecorded
talk without using my own voice.

Thanks to the people behind the scenes

who made it possible to
present this talk in a safe way.

A few words about me.

I have a long-standing interest
in the state of the Tor network.

In 2015, I started OrNetRadar,
which is a public mailing list and

website showing reports about new
relay groups and possible Sybil attacks.

In 2017, I was asked to join the private
bad-relays Tor Project mailing list

to help analyze and confirm reports
about malicious relays.

To get a better understanding of who runs
what fraction of the Tor network over time

I started OrNetStats. It shows you also
which operators could de-anonymize Tor

users because they are in a position
to perform end-to-end correlation attacks,

something we will describe later.

I'm also the maintainer of
ansible-relayor, which is an Ansible role

used by many large relay operators.

Out of curiosity, I also like
engaging in some limited open-source

intelligence gathering on malicious
Tor network actors, especially when

their motivation for running relays
has not been well understood.

To avoid confusions,
with regards to the Tor Project:

I am not employed by the Tor Project
and I do not speak for the Tor Project.

In this presentation, we will go through
some examples of malicious actors on

the Tor network. They basically represent
our problem statement that motivates us to

improve the "status quo". After describing
some issues with current approaches to

fight malicious relays, we present a new,
additional approach aiming at achieving a

safer Tor experience using trusted relays
to some extent.

The primary target audience
of this presentation are:

Tor users, like Tor Browser users,
relay operators,

onion service operators
like, for example, SecureDrop

and anyone else that cares about Tor.

To get everyone on the same page,
a quick refresher on how Tor works

and what type of relays – also
called nodes – there are.

When Alice uses Tor Browser
to visit Bob's website,

her Tor client selects three Tor relays
to construct a circuit that will be used

to route her traffic through the
Tor network before it reaches Bob.

This gives Alice location anonymity.

The first relay in such a circuit
is called an entry guard relay.

This relay is the only relay seeing
Alice's real IP address and is therefore

considered a more sensitive type of relay.
The guard relay does not learn that Alice

is connecting to Bob, though. It
only sees the next relay as destination.

Guard relays are not changed frequently,
and Alice's Tor client waits up to 12

weeks before choosing a new guard
to make some attacks less effective.

The second relay is called a middle
or middle only relay. This relay

is the least sensitive position, since it
only sees other relays, but does not know

anything about Alice or Bob because it
just forwards encrypted traffic.

And,
the final relay is called an exit relay.

The exit relay gets to learn the
destination, Bob, but does not know

who is connecting to Bob.
The exit relay is also considered

a more sensitive relay type, since it
potentially gets to see and manipulate

clear text traffic (if Alice is not using
an encrypted protocol like HTTPS.)

Although exit relays see the destination,
they can not link all sites Alice visits

at a given point in time to the same Tor
client, to profile her, because Alice's

Tor Browser instructs the Tor client to
create and use distinct circuits for

distinct URL bar domains. So, although
this diagram shows a single circuit only,

a Tor client usually has multiple open Tor
circuits at the same time. In networks

where Tor is censored, users make use of a
special node type, which is called Bridge.

Their primary difference is that they are
not included in the public list of relays,

to make it harder to censor them. Alice
has to manually configure Tor Browser if

she wants to use a bridge. For redundancy,
it is good to have more than one bridge in

case a bridge goes down or gets censored.

The used bridge also gets to see Alice's
real IP address, but not the destination.

Now that we have a basic
understanding of Tor's design,

we might wonder,
why do we need to trust the network,

when roles are distributed
across multiple relays?

So let's look into some attack scenarios.

If an attacker controls
Alice's guard and exit relay,

they can learn that Alice connected to Bob

by performing
end-to-end correlation attacks.

Such attacks can be passive,
meaning no traffic is manipulated

and therefore cannot be detected by
probing suspect relays with test traffic.

OrNetStats gives you a daily updated list
of potential operators in such a position.

There are some restrictions a default
Tor client follows when building circuits

to reduce the likelihood of this occurring

For example, a Tor client does not use
more than one relay in the same /16 IPv4

network block when building circuits. For
example, Alice's Tor client would never

create this circuit because guard and exit
relays are in the same net block one

192.0./16. For this reason, the number of
distinct /16 network blocks an attacker

distributed its relays across is relevant
when evaluating this kind of risk.

Honest relay operators declare their group
of relays in the so-called "MyFamily"

setting. This way they are transparent
about their set of relays and Tor clients

automatically avoid using more than a
single relay from any given family in a

single circuit. Malicious actors will
either not declare relay families or

pretend to be in more than one family.

Another variant of the end-to-end
correlation attack is possible

when Bob is the attacker or
has been compromised by the attacker,

and the attacker also happens to run
Alice's guard relay. In this case,

the attacker can also determine
the actual source IP address used by Alice

when she visits Bob's website.

In cases of large, suspicious, non-exit
relay groups, it is also plausible that

they are after onion services, because
circuits for onion services do not require

exit relays. Onion services provide
location anonymity to the server side.

By running many non-exits,

an attacker could aim at finding the real
IP address / location of an onion service.

Manipulating exit relays are probably
the most common attack type

detected in the wild. That is also
the easiest-to-perform attack type.

Malicious exits usually do not care who
Alice is or what her actual IP address is.

They are mainly interested to
profit from traffic manipulation.

This type of attack can be detected
by probing exits with decoy traffic,

but since malicious exits moved
to more targeted approaches

(specific domains only), detection
is less trivial than one might think.

The best protection against this
kind of attack is using encryption.

Malicious exit relays cannot harm
connections going to onion services.

Now, let's look into
two real-world examples

of large scale and persistent
malicious actors on the Tor network.

The first example, tracked as BTCMITM20,
is in the malicious exit's business and

performs SSL strip attacks on exit relays
to manipulate plaintext HTTP traffic,

like Bitcoin addresses,
to divert Bitcoin transactions to them.

They have been detected for the first time
in 2020, and had some pretty large relay

groups. On this graph, you can see how
much of the Tor exit fraction was under

their control in the first half of 2020.
The different colors represent different

contact infos they gave on their relays
to pretend they are distinct groups.

The sharp drops show events when
they were removed from the network,

before adding relays again.

In February 2021, they managed over 27%
of the Tor network's exit capacity,

despite multiple removal attempts
over almost a year.

At some point in the future,
we will hopefully have HTTPS-Only mode

enabled by default in Tor Browser
to kill this entire attack vector for good

and make malicious exits less lucrative.

I encourage you to test
HTTPS-Only mode in Tor Browser

and notify website operators
that do not work in that mode.

If a website does not work
in HTTPS-Only mode,

you also know it is probably
not safe to use in the first place.

The second example actor,
tracked as KAX17,

is still somewhat of a mystery. And
that is not the best situation to be in.

They are remarkable for:
their focus on non-exit relays,

their network diversity,
with over 200 distinct /16 subnets,

their size – it is the first actor I know
of that peaked at over 100 Gbit/s

advertised non-exit bandwidth – and
they are active since a very long time.

Let's have a look at some KAX17
related events in the past two years.

I first detected and reported them
to the Tor Project in September 2019.

In October 2019,
KAX17 relays got removed

by the Tor directory
authorities for the first time.

In December 2019,
I published the first blog post about them

At that point, they were already
rebuilding their infrastructure

by adding new relays.

In February 2020, I contacted an email
address that was used on some relays that

did not properly declare their relay group
using the "MyFamily" setting. At the time,

they said they would run bridges instead,
so they do not have to set MyFamily.

Side note:
MyFamily is not supported for bridges.

I was not aware that this email address
is linked to KAX17 until October 2021.

In the first half of 2020,
I regularly reported large quantities of

relays to the Tor Project, and they got
removed at high pace until June 2020,

when directory authorities changed their
practices and stopped removing them

because they didn't want to "scare away"
potential new relay operators.

In July 2020, an email address joined
a tor-relays mailing list discussion

I started about a proposal to limit
large-scale attacks on the network.

Now we know
that email address is linked to KAX17.

Since the Tor directory authorities
no longer removed the relay groups

showing up, I sent the information
of over 600 KAX17 relays

to the public tor-talk mailing list.

In October 2021, someone who asked for
anonymity reached out to me and provided a

new way to detect Tor relay groups that
do not run the official Tor software.

Using this methodology,
we were able to detect KAX17

using a second detection method.

This also apparently convinced
the Tor directory authorities,

and in November this year,
a major removal event took place.

Sadly, the time span during which
KAX17 was running relays without

limitations was rather long.
This motivated us to come up with a

design that avoids this kind of complete
dependency on Tor directory authorities

when it comes to safety issues.

And, as you might guess,

KAX17 is already attempting
to restore their foothold again.

Here are some KAX17 properties.

After the release of my second
KAX17 blog post in November 2021,

the media was quick with using
words like "nation-state" and

"Advanced Persistent Threat".

But I find it hard to believe such such
serious entities would be so sloppy.

Since they claim to work for an ISP
in every other email…

I looked into their AS distribution.

I guess they work for more than one ISP.

This chart shows used Autonomous System,

sorted by the unique IP addresses
used at that hoster. So, for example,

They used more than 400 IP
addresses at Microsoft to run relays.

These are not exact numbers,
since it only includes relays since 2019,

and there are likely more.
If we map their IP addresses

to countries, we get this. Do not take
this map too seriously, as the used GEOIP

database was severely outdated and such
databases are never completely accurate,

but it gives us a rough idea. To be clear,
I have no evidence that KAX17 is

performing any kind of attacks against Tor
users, but in our threat model it is

already a considerable risk if even a
benevolent operator is not declaring their

more than 800 relays as a family. Good
protections should protect against

benevolent and malicious Sybil attacks
equally. The strongest input factor for

the risk assessment of this actor is the
fact they do not run the official Tor

software on their relays. There are still
many open questions, and the analysis into

KAX17 is ongoing. If you have any input,
feel free to reach out to me. After

looking at some examples of malicious
actors, I want to shortly summarize some

of the issues in how the malicious relays
problem is currently approached. It is

pretty much like playing Whack-A-Mole. You
hit them and they come back. You hit them

again, and they come back again, over and
over and while you're at it, you're also

training them to come back stronger next
time. Malicious actors can run relays

until they get caught/detected or are
considered suspicious enough for removal

by a Tor directory authorities. If your
threat model does not match the Tor

directory's threat model, you are out of
luck or have to maintain your own

exclusion lists. Attempts to define a
former set of "do not do" requirements for

relays that Tor directory authorities
commit to enforce, have failed, even with

the involvement of a core Tor developer.
It is time for a paradigm change. The

current processes for detecting and
removing malicious Tor relays are failing

us and are not sustainable in the long
run. In recent years, malicious groups

have become larger, harder to detect,
harder to get removed and more persistent.

Here are some of our design goals. Instead
of continuing the single sided arms race

with malicious actors. We aim to empower
Tor users for self-defense without

requiring the detection of malicious Tor
relays and without, solely, depending on

Tor directly authorities for protecting us
from malicious relays. We aim to reduce

the risk of de-anonymization by using at
least a trusted guard or exit or both. We

also acknowledge it is increasingly
impossible to detect all malicious relays

using decoy traffic, therefore, we stop
depending on the detectability of

malicious relays to protect users. In
today's Tor network, we hope to not choose

a malicious guard when we pick one. In the
proposed design, we would pick a trusted

guard instead. In fact, this can be done
with today's Tor browser, if you set any

trusted relays as your bridge. Another
supported configuration would be to use

trusted guards and trusted exits. Such
designs are possible without requiring

code changes in Tor, but are cumbersome to
configure manually, since Tor only

supports relay fingerprints and does not
know about relay operator identifiers. But

what do we actually mean by trusted
relays? Trusted relays are operated by

trusted operators. These operators are
believed to run relays without malicious

intent. Trusted operators are specified by
the user. Users assign trust at the

operator, not the relay level, for
scalability reasons, and to avoid

configuration changes when an operator
changes their relays. Since users should

be able to specify trusted operators, we
need human-readable, authenticated and

globally unique operator identifiers. By
authenticated, we mean they should not be

spoofable arbitrarily like current relay
contact infos. For simplicity, we use DNS

domains as relay operator identifiers, and
we will probably restrict them to 40

characters in length. How do Authenticated
Relay Operator IDs, short AROI, work. From

an operator point of view, configuring an
AROI is easy. Step one: The operator

specifies the desired domain under her
control using Tor's ContactInfo option.

Step two: The operator publishes a simple
text file using the IANA well-known URI

containing all relay fingerprints. If no
web server is available or if the web

server is not considered safe enough,
DNSSEC-signed TXT records are also an

option for authentication. Using DNS is
great for scalability and availability due

to DNS caching, but since every relay
requires its own TXT record, it will take

longer than the URI type proof when
performing proof validation. Operators

that have no domain at all can use free
services like GitHub pages or similar to

serve the text file. For convenience, Eran
Sandler created this simple to use

ContactInfo generator, so relay operators
don't have to read the specification to

generate the required ContactInfo string
for their configuration. For the

Authenticated Relay Operator ID the "url"
and "proof" fields are the only relevant

fields. There are already over 1000 relays
that have implemented the Authenticated

Relay Operator ID. OrNetStats displays an
icon in case the operator implemented it

correctly. Out of the top 24 largest
families by bandwidth, all but eight

operators have implemented the
Authenticated Relay Operator ID already.

On the right-hand side, you can see a few
logos of organizations running relays with

a properly set up AROI. The most relevant
distinction between lines having that

checkmark icon and those that do not have
it is the fact that the string in lines

that do not include the icon can be
arbitrarily spoofed. This graph shows the

largest exit operators that implemented
the AROI. I want to stress one crucial

point about AROIs though, authenticated
must not be confused with trusted.

Malicious operators can also authenticate
their domain and they do. A given AROI can

be trusted or not. It is up to the user,
but using AROIs instead of ContactInfo for

assigning trust is crucial because
ContactInfo can not be trusted directly

without further checks. This graph shows
what fraction of the Tor network's exit

capacity implemented the Authenticated
Relay Operator ID over time. Currently, we

are at around 60 percent already, but
guard capacity is a lot lower, around 15

percent. The reason for that is that exits
are operated mostly by large operators and

organizations, while guards are
distributed across a lot more operators.

There are over 1800 guard families, but
only around 400 exit families. How does a

Tor client make use of AROIs, current Tor
versions do not know what AROIs are and

primarily take relay fingerprints as
configuration inputs. So, we need some

tooling to generate a list of relay
fingerprints starting from a list of

trusted AROIs. We have implemented a quick
and dirty proof of concept that puts

everything together and performs all the
steps shown on this slide, to demonstrate

the concept of using trusted AROIs to
configure Tor client to use trusted exit

relays. It is not meant to be used by end-
users, it merely is a preview for the

technical audience who would like to see
it in action to achieve a better

understanding of the design. The current
proof of concept performs all proof checks

itself without relying on third parties,
but since there are a lot of reasons for

doing proof-checks centrally instead, for
example, by directory authorities. I

recently submitted a partial proposal for
it to the Tor development mailing list to

see whether they would consider it before
proceeding with a more serious

implementation than the current proof of
concept. I find it important to always try

achieving a common goal together with
upstream first before creating solutions

that are maintained outside of upstream
because it will lead to better maintained

improvements and likely a more user-
friendly experience if they are integrated

in upstream. Here is a link to the
mentioned tor-dev email, for those who

would like to follow along. To summarize,
after reviewing some real world examples

of malicious actors on the Tor network, we
concluded that current approaches to limit

risks by bad relays on Tor users might not
live up to Tor users expectations, are not

sustainable in the long run and need an
upgrade to avoid depending on the

detectability of malicious relays, which
is becoming increasingly hard. We

presented a design to extend current anti
bad relay approaches that does not rely on

the detection of malicious relays using
trusted Authenticated Relay Operator IDs.

We have shown that most exit capacity has
implemented AROIs already, while guard

capacity is currently significantly lower,
showing a lack of insights on who operates

Tor's guard capacity. When publicly
speaking about modifying Tor's path

selection in front of a wide audience, I
also consider it to be my responsibility

to explicitly state that you should not
change your Tor configuration options that

influenced path selection behavior without
a clear need, according to your threat

model to avoid potentially standing out.
Using trusted AROIs certainly comes with

some tradeoffs of its own, like for
example, network load balancing, to name

only one. Thanks to many large, trusted
exit operators, it should be feasible in

the near future to use trusted exits
without standing out in a trivially

detectable way because it is harder in the
sense of takes longer to statistically

detect a Tor client changed its possible
pool of exits, if it only excluded a

smaller fraction of exits. Detecting Tor
clients using only a subset of all guards

takes a lot longer than detecting custom
exit sets because guards are not changed

over a longer period of time when compared
with exits. And finally, Tor clients that

make use of trusted AROIs will need a way
to find trusted AROIs, ideally, they could

learn about them dynamically in a safe
way. There is an early work in progress

draft specification linked on this slide.
I want to dedicate this talk to Karsten

Loesing who passed away last year. He was
the kindest person I got to interact with

in the Tor community. Karsten was the Tor
metrics team lead and without his work, my

projects, OrNetStats and OrNetRadar would
not exist. Every time you use

metrics.torproject.org, for example, the
so-called "Relay Search", you are using

his legacy. Thank you for listening, and
I'm really looking forward to your

questions. I'm not sure I'll be able to
respond to questions after the talk in

real time, but it would be nice to have
them read out. So they are part of the

recording and I'll make an effort to
publish answers to all of them via

Mastodon, should I not be able to respond
in real time. I'm also happy to take tips

about unusual things you observed on the
Tor network. Do not underestimate your

power as Tor user to contribute to a safer
Tor network by reporting unusual things.

Most major hits against bad relay actors
were the result of Tor user reports.

quietness

Herald: OK. Thank you very much for this
very informative talk and yes so we will

switch over to the Q&A now. Yeah, thanks
again. Very fascinating. So we have

collected several questions from our IRC
chat, so I'm just going to start. If

bridges don't need the MyFamily setting
isn't this a wide open gap for end-to-end

correlation attacks, for example if a
malicious actor can somehow make the relay

popular as bridge?
Nusenu: Yes, bridges are a concern in the

context of MyFamily, for that reason, it
is not recommended to run bridges and

exits at the same time in current versions
of Tor, but future versions of Tor will

get a new and more relay operator friendly
MyFamily setting. That new MyFamily design

will also support bridges. This will
likely be in Tor 0.4.8.x at some point in

2022.
Herald: OK, thanks. Despite what kind of

attack, are there statistics who or from
which country these attacks are coming

most? Background here is there are rumors
about NSA driven and exit notes.

Nusenu: I don't know about any general
statistics, but I usually include used

autonomous systems by certain groups when
blogging about them. There are some

autonomous systems that are notorious for
being used by malicious groups, but

malicious groups also try to blend in with
the rest by using large ISPs like Hetzner

and OVH.
Herald: Thanks. Is using a bridge that I

host also safer than using a random guard
node?

Nusenu: This is a tricky question, since
it also depends on whether it is a private

bridge, a bridge that is not distributed
to other uses by a bridgeDB. I would say

it is better to not run the bridges you
use yourself.

Herald: OK. What is worse? KAX17 or a well
known trusted operators running 20 percent

of Tor's exits?
Nusenu: Currently, I would say KAX17.

Herald: OK. I think that's the last one
for now: Isn't the anonymity, not

decreased or changed while using trusted
relay list?

Nusenu: Yes, this is a trade-off that
users will need to make. This heavily

depends on the threat model.
Herald: OK. So I think we have gathered

all the questions and they were all
answered. So thank you again for. Yes,

thank you again.

rc3 postroll music

Subtitles created by c3subtitles.de
in the year 2022. Join, and help us!#