WEBVTT
00:00:00.000 --> 00:00:07.945
intro music
00:00:07.945 --> 00:00:13.074
Herald: This is now
"Towards a more trustworthy Tor network"
00:00:13.074 --> 00:00:15.109
by Nusenu
00:00:15.109 --> 00:00:21.578
The talk will give examples of malicious
relay groups and current issues and how to
00:00:21.578 --> 00:00:28.250
tackle those to empower Tor users for
self-defense, so they don't necessarily
00:00:28.250 --> 00:00:31.821
need to rely on the detection and removal
of those groups.
00:00:31.821 --> 00:00:36.284
So without further ado, enjoy!
00:00:36.284 --> 00:00:40.767
And we will see each other
for Q&A afterwards.
00:00:45.531 --> 00:00:49.620
Nusenu: Thanks for inviting me to give a
talk about something I deeply care about:
00:00:49.620 --> 00:00:51.748
The Tor network.
00:00:51.748 --> 00:00:54.273
The Tor network
is a crucial privacy infrastructure,
00:00:54.273 --> 00:00:57.338
without which,
we could not use Tor Browser.
00:00:57.338 --> 00:01:02.259
I like to uncover malicious Tor relays
to help protect Tor users.
00:01:02.259 --> 00:01:06.707
But since that does not come without
personal risks, I'm taking steps
00:01:06.707 --> 00:01:10.243
to protect myself from those
running those malicious nodes,
00:01:10.243 --> 00:01:12.819
so I can continue to fight them.
00:01:12.819 --> 00:01:17.664
For this reason, this is a prerecorded
talk without using my own voice.
00:01:18.375 --> 00:01:20.638
Thanks to the people behind the scenes
00:01:20.638 --> 00:01:24.770
who made it possible to
present this talk in a safe way.
00:01:26.881 --> 00:01:28.875
A few words about me.
00:01:28.875 --> 00:01:32.150
I have a long-standing interest
in the state of the Tor network.
00:01:32.150 --> 00:01:37.894
In 2015, I started OrNetRadar,
which is a public mailing list and
00:01:37.894 --> 00:01:43.481
website showing reports about new
relay groups and possible Sybil attacks.
00:01:43.481 --> 00:01:50.176
In 2017, I was asked to join the private
bad-relays Tor Project mailing list
00:01:50.176 --> 00:01:55.030
to help analyze and confirm reports
about malicious relays.
00:01:56.434 --> 00:02:01.091
To get a better understanding of who runs
what fraction of the Tor network over time
00:02:01.091 --> 00:02:07.540
I started OrNetStats. It shows you also
which operators could de-anonymize Tor
00:02:07.540 --> 00:02:12.551
users because they are in a position
to perform end-to-end correlation attacks,
00:02:12.551 --> 00:02:14.817
something we will describe later.
00:02:14.817 --> 00:02:19.919
I'm also the maintainer of
ansible-relayor, which is an Ansible role
00:02:19.919 --> 00:02:22.932
used by many large relay operators.
00:02:23.410 --> 00:02:27.691
Out of curiosity, I also like
engaging in some limited open-source
00:02:27.691 --> 00:02:32.271
intelligence gathering on malicious
Tor network actors, especially when
00:02:32.271 --> 00:02:35.761
their motivation for running relays
has not been well understood.
00:02:36.601 --> 00:02:39.619
To avoid confusions,
with regards to the Tor Project:
00:02:39.619 --> 00:02:45.015
I am not employed by the Tor Project
and I do not speak for the Tor Project.
00:02:47.886 --> 00:02:52.844
In this presentation, we will go through
some examples of malicious actors on
00:02:52.844 --> 00:02:58.560
the Tor network. They basically represent
our problem statement that motivates us to
00:02:58.560 --> 00:03:04.030
improve the "status quo". After describing
some issues with current approaches to
00:03:04.030 --> 00:03:09.060
fight malicious relays, we present a new,
additional approach aiming at achieving a
00:03:09.060 --> 00:03:13.738
safer Tor experience using trusted relays
to some extent.
00:03:14.757 --> 00:03:17.867
The primary target audience
of this presentation are:
00:03:17.867 --> 00:03:24.737
Tor users, like Tor Browser users,
relay operators,
00:03:24.737 --> 00:03:29.172
onion service operators
like, for example, SecureDrop
00:03:29.172 --> 00:03:33.034
and anyone else that cares about Tor.
00:03:35.796 --> 00:03:40.604
To get everyone on the same page,
a quick refresher on how Tor works
00:03:40.604 --> 00:03:45.191
and what type of relays – also
called nodes – there are.
00:03:45.191 --> 00:03:50.190
When Alice uses Tor Browser
to visit Bob's website,
00:03:50.190 --> 00:03:56.014
her Tor client selects three Tor relays
to construct a circuit that will be used
00:03:56.014 --> 00:04:00.471
to route her traffic through the
Tor network before it reaches Bob.
00:04:00.471 --> 00:04:03.869
This gives Alice location anonymity.
00:04:03.869 --> 00:04:08.831
The first relay in such a circuit
is called an entry guard relay.
00:04:08.831 --> 00:04:14.803
This relay is the only relay seeing
Alice's real IP address and is therefore
00:04:14.803 --> 00:04:20.593
considered a more sensitive type of relay.
The guard relay does not learn that Alice
00:04:20.593 --> 00:04:25.740
is connecting to Bob, though. It
only sees the next relay as destination.
00:04:25.740 --> 00:04:30.934
Guard relays are not changed frequently,
and Alice's Tor client waits up to 12
00:04:30.934 --> 00:04:35.767
weeks before choosing a new guard
to make some attacks less effective.
00:04:35.767 --> 00:04:42.397
The second relay is called a middle
or middle only relay. This relay
00:04:42.397 --> 00:04:46.960
is the least sensitive position, since it
only sees other relays, but does not know
00:04:46.960 --> 00:04:51.136
anything about Alice or Bob because it
just forwards encrypted traffic.
00:04:51.601 --> 00:04:56.394
And,
the final relay is called an exit relay.
00:04:56.394 --> 00:05:00.992
The exit relay gets to learn the
destination, Bob, but does not know
00:05:00.992 --> 00:05:06.200
who is connecting to Bob.
The exit relay is also considered
00:05:06.200 --> 00:05:11.350
a more sensitive relay type, since it
potentially gets to see and manipulate
00:05:11.350 --> 00:05:20.130
clear text traffic (if Alice is not using
an encrypted protocol like HTTPS.)
00:05:20.130 --> 00:05:25.690
Although exit relays see the destination,
they can not link all sites Alice visits
00:05:25.690 --> 00:05:31.860
at a given point in time to the same Tor
client, to profile her, because Alice's
00:05:31.860 --> 00:05:36.310
Tor Browser instructs the Tor client to
create and use distinct circuits for
00:05:36.310 --> 00:05:42.930
distinct URL bar domains. So, although
this diagram shows a single circuit only,
00:05:42.930 --> 00:05:49.031
a Tor client usually has multiple open Tor
circuits at the same time. In networks
00:05:49.031 --> 00:05:56.496
where Tor is censored, users make use of a
special node type, which is called Bridge.
00:05:56.496 --> 00:06:01.640
Their primary difference is that they are
not included in the public list of relays,
00:06:01.640 --> 00:06:07.190
to make it harder to censor them. Alice
has to manually configure Tor Browser if
00:06:07.190 --> 00:06:13.280
she wants to use a bridge. For redundancy,
it is good to have more than one bridge in
00:06:13.280 --> 00:06:16.310
case a bridge goes down or gets censored.
00:06:16.310 --> 00:06:22.030
The used bridge also gets to see Alice's
real IP address, but not the destination.
00:06:24.676 --> 00:06:28.328
Now that we have a basic
understanding of Tor's design,
00:06:28.328 --> 00:06:30.674
we might wonder,
why do we need to trust the network,
00:06:30.674 --> 00:06:35.547
when roles are distributed
across multiple relays?
00:06:35.547 --> 00:06:38.848
So let's look into some attack scenarios.
00:06:40.720 --> 00:06:44.722
If an attacker controls
Alice's guard and exit relay,
00:06:44.722 --> 00:06:47.461
they can learn that Alice connected to Bob
00:06:47.461 --> 00:06:51.147
by performing
end-to-end correlation attacks.
00:06:51.147 --> 00:06:56.559
Such attacks can be passive,
meaning no traffic is manipulated
00:06:56.559 --> 00:07:02.111
and therefore cannot be detected by
probing suspect relays with test traffic.
00:07:03.203 --> 00:07:09.633
OrNetStats gives you a daily updated list
of potential operators in such a position.
00:07:09.633 --> 00:07:15.401
There are some restrictions a default
Tor client follows when building circuits
00:07:15.401 --> 00:07:19.019
to reduce the likelihood of this occurring
00:07:19.019 --> 00:07:24.608
For example, a Tor client does not use
more than one relay in the same /16 IPv4
00:07:24.608 --> 00:07:30.930
network block when building circuits. For
example, Alice's Tor client would never
00:07:30.930 --> 00:07:36.430
create this circuit because guard and exit
relays are in the same net block one
00:07:36.430 --> 00:07:45.620
192.0./16. For this reason, the number of
distinct /16 network blocks an attacker
00:07:45.620 --> 00:07:51.776
distributed its relays across is relevant
when evaluating this kind of risk.
00:07:51.776 --> 00:07:59.400
Honest relay operators declare their group
of relays in the so-called "MyFamily"
00:07:59.400 --> 00:08:04.639
setting. This way they are transparent
about their set of relays and Tor clients
00:08:04.639 --> 00:08:09.090
automatically avoid using more than a
single relay from any given family in a
00:08:09.090 --> 00:08:14.770
single circuit. Malicious actors will
either not declare relay families or
00:08:14.770 --> 00:08:17.611
pretend to be in more than one family.
00:08:19.891 --> 00:08:24.681
Another variant of the end-to-end
correlation attack is possible
00:08:24.681 --> 00:08:28.948
when Bob is the attacker or
has been compromised by the attacker,
00:08:28.948 --> 00:08:34.871
and the attacker also happens to run
Alice's guard relay. In this case,
00:08:34.871 --> 00:08:40.879
the attacker can also determine
the actual source IP address used by Alice
00:08:40.879 --> 00:08:43.329
when she visits Bob's website.
00:08:45.496 --> 00:08:50.466
In cases of large, suspicious, non-exit
relay groups, it is also plausible that
00:08:50.466 --> 00:08:54.406
they are after onion services, because
circuits for onion services do not require
00:08:54.406 --> 00:09:01.965
exit relays. Onion services provide
location anonymity to the server side.
00:09:01.965 --> 00:09:04.180
By running many non-exits,
00:09:04.180 --> 00:09:10.958
an attacker could aim at finding the real
IP address / location of an onion service.
00:09:13.037 --> 00:09:17.549
Manipulating exit relays are probably
the most common attack type
00:09:17.549 --> 00:09:23.034
detected in the wild. That is also
the easiest-to-perform attack type.
00:09:23.034 --> 00:09:29.743
Malicious exits usually do not care who
Alice is or what her actual IP address is.
00:09:29.743 --> 00:09:34.503
They are mainly interested to
profit from traffic manipulation.
00:09:35.488 --> 00:09:40.737
This type of attack can be detected
by probing exits with decoy traffic,
00:09:40.737 --> 00:09:45.159
but since malicious exits moved
to more targeted approaches
00:09:45.159 --> 00:09:50.182
(specific domains only), detection
is less trivial than one might think.
00:09:51.380 --> 00:09:56.071
The best protection against this
kind of attack is using encryption.
00:09:56.071 --> 00:10:00.999
Malicious exit relays cannot harm
connections going to onion services.
00:10:02.892 --> 00:10:06.629
Now, let's look into
two real-world examples
00:10:06.629 --> 00:10:10.474
of large scale and persistent
malicious actors on the Tor network.
00:10:12.507 --> 00:10:20.060
The first example, tracked as BTCMITM20,
is in the malicious exit's business and
00:10:20.060 --> 00:10:26.980
performs SSL strip attacks on exit relays
to manipulate plaintext HTTP traffic,
00:10:26.980 --> 00:10:31.901
like Bitcoin addresses,
to divert Bitcoin transactions to them.
00:10:31.901 --> 00:10:37.981
They have been detected for the first time
in 2020, and had some pretty large relay
00:10:37.981 --> 00:10:44.332
groups. On this graph, you can see how
much of the Tor exit fraction was under
00:10:44.332 --> 00:10:50.230
their control in the first half of 2020.
The different colors represent different
00:10:50.230 --> 00:10:56.248
contact infos they gave on their relays
to pretend they are distinct groups.
00:10:56.248 --> 00:11:00.026
The sharp drops show events when
they were removed from the network,
00:11:00.026 --> 00:11:02.661
before adding relays again.
00:11:03.968 --> 00:11:11.647
In February 2021, they managed over 27%
of the Tor network's exit capacity,
00:11:11.647 --> 00:11:15.838
despite multiple removal attempts
over almost a year.
00:11:16.721 --> 00:11:23.143
At some point in the future,
we will hopefully have HTTPS-Only mode
00:11:23.143 --> 00:11:28.449
enabled by default in Tor Browser
to kill this entire attack vector for good
00:11:28.449 --> 00:11:32.203
and make malicious exits less lucrative.
00:11:32.203 --> 00:11:37.242
I encourage you to test
HTTPS-Only mode in Tor Browser
00:11:37.242 --> 00:11:42.135
and notify website operators
that do not work in that mode.
00:11:42.135 --> 00:11:45.586
If a website does not work
in HTTPS-Only mode,
00:11:45.586 --> 00:11:50.078
you also know it is probably
not safe to use in the first place.
00:11:51.806 --> 00:11:57.106
The second example actor,
tracked as KAX17,
00:11:57.106 --> 00:12:02.728
is still somewhat of a mystery. And
that is not the best situation to be in.
00:12:02.728 --> 00:12:07.032
They are remarkable for:
their focus on non-exit relays,
00:12:07.032 --> 00:12:13.036
their network diversity,
with over 200 distinct /16 subnets,
00:12:13.036 --> 00:12:19.432
their size – it is the first actor I know
of that peaked at over 100 Gbit/s
00:12:19.432 --> 00:12:25.684
advertised non-exit bandwidth – and
they are active since a very long time.
00:12:27.422 --> 00:12:32.059
Let's have a look at some KAX17
related events in the past two years.
00:12:32.059 --> 00:12:38.856
I first detected and reported them
to the Tor Project in September 2019.
00:12:38.856 --> 00:12:44.084
In October 2019,
KAX17 relays got removed
00:12:44.084 --> 00:12:47.459
by the Tor directory
authorities for the first time.
00:12:49.756 --> 00:12:54.212
In December 2019,
I published the first blog post about them
00:12:54.212 --> 00:12:57.783
At that point, they were already
rebuilding their infrastructure
00:12:57.783 --> 00:13:00.576
by adding new relays.
00:13:01.827 --> 00:13:07.791
In February 2020, I contacted an email
address that was used on some relays that
00:13:07.791 --> 00:13:13.339
did not properly declare their relay group
using the "MyFamily" setting. At the time,
00:13:13.339 --> 00:13:18.640
they said they would run bridges instead,
so they do not have to set MyFamily.
00:13:18.640 --> 00:13:23.814
Side note:
MyFamily is not supported for bridges.
00:13:23.814 --> 00:13:30.292
I was not aware that this email address
is linked to KAX17 until October 2021.
00:13:31.208 --> 00:13:37.709
In the first half of 2020,
I regularly reported large quantities of
00:13:37.709 --> 00:13:43.914
relays to the Tor Project, and they got
removed at high pace until June 2020,
00:13:43.914 --> 00:13:48.444
when directory authorities changed their
practices and stopped removing them
00:13:48.444 --> 00:13:53.600
because they didn't want to "scare away"
potential new relay operators.
00:13:54.859 --> 00:13:58.524
In July 2020, an email address joined
a tor-relays mailing list discussion
00:13:58.524 --> 00:14:07.178
I started about a proposal to limit
large-scale attacks on the network.
00:14:07.178 --> 00:14:12.725
Now we know
that email address is linked to KAX17.
00:14:13.920 --> 00:14:18.445
Since the Tor directory authorities
no longer removed the relay groups
00:14:18.445 --> 00:14:24.090
showing up, I sent the information
of over 600 KAX17 relays
00:14:24.090 --> 00:14:26.518
to the public tor-talk mailing list.
00:14:27.703 --> 00:14:32.321
In October 2021, someone who asked for
anonymity reached out to me and provided a
00:14:32.321 --> 00:14:39.287
new way to detect Tor relay groups that
do not run the official Tor software.
00:14:40.518 --> 00:14:45.351
Using this methodology,
we were able to detect KAX17
00:14:45.351 --> 00:14:47.722
using a second detection method.
00:14:47.722 --> 00:14:52.224
This also apparently convinced
the Tor directory authorities,
00:14:52.224 --> 00:14:57.095
and in November this year,
a major removal event took place.
00:14:58.530 --> 00:15:03.889
Sadly, the time span during which
KAX17 was running relays without
00:15:03.889 --> 00:15:11.480
limitations was rather long.
This motivated us to come up with a
00:15:11.480 --> 00:15:16.598
design that avoids this kind of complete
dependency on Tor directory authorities
00:15:16.598 --> 00:15:19.262
when it comes to safety issues.
00:15:20.032 --> 00:15:22.810
And, as you might guess,
00:15:22.810 --> 00:15:27.372
KAX17 is already attempting
to restore their foothold again.
00:15:30.009 --> 00:15:33.404
Here are some KAX17 properties.
00:15:33.404 --> 00:15:39.502
After the release of my second
KAX17 blog post in November 2021,
00:15:39.502 --> 00:15:43.819
the media was quick with using
words like "nation-state" and
00:15:43.819 --> 00:15:46.860
"Advanced Persistent Threat".
00:15:46.860 --> 00:15:53.175
But I find it hard to believe such such
serious entities would be so sloppy.
00:15:53.175 --> 00:15:58.061
Since they claim to work for an ISP
in every other email…
00:15:58.797 --> 00:16:02.144
I looked into their AS distribution.
00:16:02.800 --> 00:16:06.881
I guess they work for more than one ISP.
00:16:07.686 --> 00:16:10.625
This chart shows used Autonomous System,
00:16:10.625 --> 00:16:15.972
sorted by the unique IP addresses
used at that hoster. So, for example,
00:16:15.972 --> 00:16:21.178
They used more than 400 IP
addresses at Microsoft to run relays.
00:16:21.178 --> 00:16:27.009
These are not exact numbers,
since it only includes relays since 2019,
00:16:27.009 --> 00:16:33.019
and there are likely more.
If we map their IP addresses
00:16:33.019 --> 00:16:39.050
to countries, we get this. Do not take
this map too seriously, as the used GEOIP
00:16:39.050 --> 00:16:44.819
database was severely outdated and such
databases are never completely accurate,
00:16:44.819 --> 00:16:54.980
but it gives us a rough idea. To be clear,
I have no evidence that KAX17 is
00:16:54.980 --> 00:17:00.670
performing any kind of attacks against Tor
users, but in our threat model it is
00:17:00.670 --> 00:17:06.069
already a considerable risk if even a
benevolent operator is not declaring their
00:17:06.069 --> 00:17:12.039
more than 800 relays as a family. Good
protections should protect against
00:17:12.039 --> 00:17:17.809
benevolent and malicious Sybil attacks
equally. The strongest input factor for
00:17:17.809 --> 00:17:23.240
the risk assessment of this actor is the
fact they do not run the official Tor
00:17:23.240 --> 00:17:28.769
software on their relays. There are still
many open questions, and the analysis into
00:17:28.769 --> 00:17:39.370
KAX17 is ongoing. If you have any input,
feel free to reach out to me. After
00:17:39.370 --> 00:17:44.419
looking at some examples of malicious
actors, I want to shortly summarize some
00:17:44.419 --> 00:17:51.519
of the issues in how the malicious relays
problem is currently approached. It is
00:17:51.519 --> 00:17:56.690
pretty much like playing Whack-A-Mole. You
hit them and they come back. You hit them
00:17:56.690 --> 00:18:02.620
again, and they come back again, over and
over and while you're at it, you're also
00:18:02.620 --> 00:18:08.580
training them to come back stronger next
time. Malicious actors can run relays
00:18:08.580 --> 00:18:14.669
until they get caught/detected or are
considered suspicious enough for removal
00:18:14.669 --> 00:18:20.630
by a Tor directory authorities. If your
threat model does not match the Tor
00:18:20.630 --> 00:18:25.179
directory's threat model, you are out of
luck or have to maintain your own
00:18:25.179 --> 00:18:31.370
exclusion lists. Attempts to define a
former set of "do not do" requirements for
00:18:31.370 --> 00:18:36.991
relays that Tor directory authorities
commit to enforce, have failed, even with
00:18:36.991 --> 00:18:45.760
the involvement of a core Tor developer.
It is time for a paradigm change. The
00:18:45.760 --> 00:18:50.799
current processes for detecting and
removing malicious Tor relays are failing
00:18:50.799 --> 00:18:56.660
us and are not sustainable in the long
run. In recent years, malicious groups
00:18:56.660 --> 00:19:05.660
have become larger, harder to detect,
harder to get removed and more persistent.
00:19:05.660 --> 00:19:11.970
Here are some of our design goals. Instead
of continuing the single sided arms race
00:19:11.970 --> 00:19:17.389
with malicious actors. We aim to empower
Tor users for self-defense without
00:19:17.389 --> 00:19:22.260
requiring the detection of malicious Tor
relays and without, solely, depending on
00:19:22.260 --> 00:19:28.389
Tor directly authorities for protecting us
from malicious relays. We aim to reduce
00:19:28.389 --> 00:19:36.899
the risk of de-anonymization by using at
least a trusted guard or exit or both. We
00:19:36.899 --> 00:19:41.440
also acknowledge it is increasingly
impossible to detect all malicious relays
00:19:41.440 --> 00:19:46.990
using decoy traffic, therefore, we stop
depending on the detectability of
00:19:46.990 --> 00:19:56.270
malicious relays to protect users. In
today's Tor network, we hope to not choose
00:19:56.270 --> 00:20:01.519
a malicious guard when we pick one. In the
proposed design, we would pick a trusted
00:20:01.519 --> 00:20:07.620
guard instead. In fact, this can be done
with today's Tor browser, if you set any
00:20:07.620 --> 00:20:14.289
trusted relays as your bridge. Another
supported configuration would be to use
00:20:14.289 --> 00:20:20.169
trusted guards and trusted exits. Such
designs are possible without requiring
00:20:20.169 --> 00:20:25.370
code changes in Tor, but are cumbersome to
configure manually, since Tor only
00:20:25.370 --> 00:20:33.310
supports relay fingerprints and does not
know about relay operator identifiers. But
00:20:33.310 --> 00:20:39.460
what do we actually mean by trusted
relays? Trusted relays are operated by
00:20:39.460 --> 00:20:45.380
trusted operators. These operators are
believed to run relays without malicious
00:20:45.380 --> 00:20:51.559
intent. Trusted operators are specified by
the user. Users assign trust at the
00:20:51.559 --> 00:20:57.450
operator, not the relay level, for
scalability reasons, and to avoid
00:20:57.450 --> 00:21:05.990
configuration changes when an operator
changes their relays. Since users should
00:21:05.990 --> 00:21:12.100
be able to specify trusted operators, we
need human-readable, authenticated and
00:21:12.100 --> 00:21:19.029
globally unique operator identifiers. By
authenticated, we mean they should not be
00:21:19.029 --> 00:21:26.700
spoofable arbitrarily like current relay
contact infos. For simplicity, we use DNS
00:21:26.700 --> 00:21:34.140
domains as relay operator identifiers, and
we will probably restrict them to 40
00:21:34.140 --> 00:21:47.000
characters in length. How do Authenticated
Relay Operator IDs, short AROI, work. From
00:21:47.000 --> 00:21:52.490
an operator point of view, configuring an
AROI is easy. Step one: The operator
00:21:52.490 --> 00:21:59.559
specifies the desired domain under her
control using Tor's ContactInfo option.
00:21:59.559 --> 00:22:06.850
Step two: The operator publishes a simple
text file using the IANA well-known URI
00:22:06.850 --> 00:22:13.100
containing all relay fingerprints. If no
web server is available or if the web
00:22:13.100 --> 00:22:18.710
server is not considered safe enough,
DNSSEC-signed TXT records are also an
00:22:18.710 --> 00:22:25.580
option for authentication. Using DNS is
great for scalability and availability due
00:22:25.580 --> 00:22:31.299
to DNS caching, but since every relay
requires its own TXT record, it will take
00:22:31.299 --> 00:22:37.110
longer than the URI type proof when
performing proof validation. Operators
00:22:37.110 --> 00:22:42.370
that have no domain at all can use free
services like GitHub pages or similar to
00:22:42.370 --> 00:22:49.870
serve the text file. For convenience, Eran
Sandler created this simple to use
00:22:49.870 --> 00:22:55.100
ContactInfo generator, so relay operators
don't have to read the specification to
00:22:55.100 --> 00:23:00.530
generate the required ContactInfo string
for their configuration. For the
00:23:00.530 --> 00:23:06.290
Authenticated Relay Operator ID the "url"
and "proof" fields are the only relevant
00:23:06.290 --> 00:23:13.720
fields. There are already over 1000 relays
that have implemented the Authenticated
00:23:13.720 --> 00:23:21.690
Relay Operator ID. OrNetStats displays an
icon in case the operator implemented it
00:23:21.690 --> 00:23:29.110
correctly. Out of the top 24 largest
families by bandwidth, all but eight
00:23:29.110 --> 00:23:34.720
operators have implemented the
Authenticated Relay Operator ID already.
00:23:34.720 --> 00:23:40.380
On the right-hand side, you can see a few
logos of organizations running relays with
00:23:40.380 --> 00:23:46.639
a properly set up AROI. The most relevant
distinction between lines having that
00:23:46.639 --> 00:23:51.790
checkmark icon and those that do not have
it is the fact that the string in lines
00:23:51.790 --> 00:23:59.409
that do not include the icon can be
arbitrarily spoofed. This graph shows the
00:23:59.409 --> 00:24:05.549
largest exit operators that implemented
the AROI. I want to stress one crucial
00:24:05.549 --> 00:24:12.660
point about AROIs though, authenticated
must not be confused with trusted.
00:24:12.660 --> 00:24:19.200
Malicious operators can also authenticate
their domain and they do. A given AROI can
00:24:19.200 --> 00:24:25.529
be trusted or not. It is up to the user,
but using AROIs instead of ContactInfo for
00:24:25.529 --> 00:24:30.669
assigning trust is crucial because
ContactInfo can not be trusted directly
00:24:30.669 --> 00:24:37.840
without further checks. This graph shows
what fraction of the Tor network's exit
00:24:37.840 --> 00:24:43.769
capacity implemented the Authenticated
Relay Operator ID over time. Currently, we
00:24:43.769 --> 00:24:49.529
are at around 60 percent already, but
guard capacity is a lot lower, around 15
00:24:49.529 --> 00:24:55.880
percent. The reason for that is that exits
are operated mostly by large operators and
00:24:55.880 --> 00:25:00.909
organizations, while guards are
distributed across a lot more operators.
00:25:00.909 --> 00:25:11.450
There are over 1800 guard families, but
only around 400 exit families. How does a
00:25:11.450 --> 00:25:19.380
Tor client make use of AROIs, current Tor
versions do not know what AROIs are and
00:25:19.380 --> 00:25:24.690
primarily take relay fingerprints as
configuration inputs. So, we need some
00:25:24.690 --> 00:25:28.980
tooling to generate a list of relay
fingerprints starting from a list of
00:25:28.980 --> 00:25:36.919
trusted AROIs. We have implemented a quick
and dirty proof of concept that puts
00:25:36.919 --> 00:25:41.370
everything together and performs all the
steps shown on this slide, to demonstrate
00:25:41.370 --> 00:25:47.100
the concept of using trusted AROIs to
configure Tor client to use trusted exit
00:25:47.100 --> 00:25:53.639
relays. It is not meant to be used by end-
users, it merely is a preview for the
00:25:53.639 --> 00:25:57.570
technical audience who would like to see
it in action to achieve a better
00:25:57.570 --> 00:26:03.870
understanding of the design. The current
proof of concept performs all proof checks
00:26:03.870 --> 00:26:09.799
itself without relying on third parties,
but since there are a lot of reasons for
00:26:09.799 --> 00:26:15.080
doing proof-checks centrally instead, for
example, by directory authorities. I
00:26:15.080 --> 00:26:21.080
recently submitted a partial proposal for
it to the Tor development mailing list to
00:26:21.080 --> 00:26:25.080
see whether they would consider it before
proceeding with a more serious
00:26:25.080 --> 00:26:30.950
implementation than the current proof of
concept. I find it important to always try
00:26:30.950 --> 00:26:35.820
achieving a common goal together with
upstream first before creating solutions
00:26:35.820 --> 00:26:40.769
that are maintained outside of upstream
because it will lead to better maintained
00:26:40.769 --> 00:26:46.179
improvements and likely a more user-
friendly experience if they are integrated
00:26:46.179 --> 00:26:52.909
in upstream. Here is a link to the
mentioned tor-dev email, for those who
00:26:52.909 --> 00:27:01.789
would like to follow along. To summarize,
after reviewing some real world examples
00:27:01.789 --> 00:27:08.200
of malicious actors on the Tor network, we
concluded that current approaches to limit
00:27:08.200 --> 00:27:16.269
risks by bad relays on Tor users might not
live up to Tor users expectations, are not
00:27:16.269 --> 00:27:22.490
sustainable in the long run and need an
upgrade to avoid depending on the
00:27:22.490 --> 00:27:28.610
detectability of malicious relays, which
is becoming increasingly hard. We
00:27:28.610 --> 00:27:34.909
presented a design to extend current anti
bad relay approaches that does not rely on
00:27:34.909 --> 00:27:41.340
the detection of malicious relays using
trusted Authenticated Relay Operator IDs.
00:27:41.340 --> 00:27:47.080
We have shown that most exit capacity has
implemented AROIs already, while guard
00:27:47.080 --> 00:27:53.289
capacity is currently significantly lower,
showing a lack of insights on who operates
00:27:53.289 --> 00:28:00.100
Tor's guard capacity. When publicly
speaking about modifying Tor's path
00:28:00.100 --> 00:28:06.590
selection in front of a wide audience, I
also consider it to be my responsibility
00:28:06.590 --> 00:28:12.759
to explicitly state that you should not
change your Tor configuration options that
00:28:12.759 --> 00:28:18.380
influenced path selection behavior without
a clear need, according to your threat
00:28:18.380 --> 00:28:26.230
model to avoid potentially standing out.
Using trusted AROIs certainly comes with
00:28:26.230 --> 00:28:31.990
some tradeoffs of its own, like for
example, network load balancing, to name
00:28:31.990 --> 00:28:38.570
only one. Thanks to many large, trusted
exit operators, it should be feasible in
00:28:38.570 --> 00:28:43.090
the near future to use trusted exits
without standing out in a trivially
00:28:43.090 --> 00:28:49.259
detectable way because it is harder in the
sense of takes longer to statistically
00:28:49.259 --> 00:28:55.110
detect a Tor client changed its possible
pool of exits, if it only excluded a
00:28:55.110 --> 00:29:02.519
smaller fraction of exits. Detecting Tor
clients using only a subset of all guards
00:29:02.519 --> 00:29:08.539
takes a lot longer than detecting custom
exit sets because guards are not changed
00:29:08.539 --> 00:29:16.120
over a longer period of time when compared
with exits. And finally, Tor clients that
00:29:16.120 --> 00:29:22.860
make use of trusted AROIs will need a way
to find trusted AROIs, ideally, they could
00:29:22.860 --> 00:29:29.789
learn about them dynamically in a safe
way. There is an early work in progress
00:29:29.789 --> 00:29:40.399
draft specification linked on this slide.
I want to dedicate this talk to Karsten
00:29:40.399 --> 00:29:47.309
Loesing who passed away last year. He was
the kindest person I got to interact with
00:29:47.309 --> 00:29:54.059
in the Tor community. Karsten was the Tor
metrics team lead and without his work, my
00:29:54.059 --> 00:29:59.830
projects, OrNetStats and OrNetRadar would
not exist. Every time you use
00:29:59.830 --> 00:30:07.389
metrics.torproject.org, for example, the
so-called "Relay Search", you are using
00:30:07.389 --> 00:30:14.730
his legacy. Thank you for listening, and
I'm really looking forward to your
00:30:14.730 --> 00:30:19.629
questions. I'm not sure I'll be able to
respond to questions after the talk in
00:30:19.629 --> 00:30:23.980
real time, but it would be nice to have
them read out. So they are part of the
00:30:23.980 --> 00:30:28.659
recording and I'll make an effort to
publish answers to all of them via
00:30:28.659 --> 00:30:35.679
Mastodon, should I not be able to respond
in real time. I'm also happy to take tips
00:30:35.679 --> 00:30:40.720
about unusual things you observed on the
Tor network. Do not underestimate your
00:30:40.720 --> 00:30:48.200
power as Tor user to contribute to a safer
Tor network by reporting unusual things.
00:30:48.200 --> 00:30:55.050
Most major hits against bad relay actors
were the result of Tor user reports.
00:30:55.050 --> 00:31:18.540
quietness
00:31:18.540 --> 00:31:27.809
Herald: OK. Thank you very much for this
very informative talk and yes so we will
00:31:27.809 --> 00:31:41.059
switch over to the Q&A now. Yeah, thanks
again. Very fascinating. So we have
00:31:41.059 --> 00:31:50.609
collected several questions from our IRC
chat, so I'm just going to start. If
00:31:50.609 --> 00:31:57.270
bridges don't need the MyFamily setting
isn't this a wide open gap for end-to-end
00:31:57.270 --> 00:32:03.840
correlation attacks, for example if a
malicious actor can somehow make the relay
00:32:03.840 --> 00:32:10.179
popular as bridge?
Nusenu: Yes, bridges are a concern in the
00:32:10.179 --> 00:32:15.419
context of MyFamily, for that reason, it
is not recommended to run bridges and
00:32:15.419 --> 00:32:20.200
exits at the same time in current versions
of Tor, but future versions of Tor will
00:32:20.200 --> 00:32:26.200
get a new and more relay operator friendly
MyFamily setting. That new MyFamily design
00:32:26.200 --> 00:32:33.539
will also support bridges. This will
likely be in Tor 0.4.8.x at some point in
00:32:33.539 --> 00:32:45.110
2022.
Herald: OK, thanks. Despite what kind of
00:32:45.110 --> 00:32:55.120
attack, are there statistics who or from
which country these attacks are coming
00:32:55.120 --> 00:33:02.799
most? Background here is there are rumors
about NSA driven and exit notes.
00:33:02.799 --> 00:33:08.389
Nusenu: I don't know about any general
statistics, but I usually include used
00:33:08.389 --> 00:33:13.610
autonomous systems by certain groups when
blogging about them. There are some
00:33:13.610 --> 00:33:17.899
autonomous systems that are notorious for
being used by malicious groups, but
00:33:17.899 --> 00:33:23.200
malicious groups also try to blend in with
the rest by using large ISPs like Hetzner
00:33:23.200 --> 00:33:30.750
and OVH.
Herald: Thanks. Is using a bridge that I
00:33:30.750 --> 00:33:35.009
host also safer than using a random guard
node?
00:33:35.009 --> 00:33:41.790
Nusenu: This is a tricky question, since
it also depends on whether it is a private
00:33:41.790 --> 00:33:47.380
bridge, a bridge that is not distributed
to other uses by a bridgeDB. I would say
00:33:47.380 --> 00:33:53.470
it is better to not run the bridges you
use yourself.
00:33:53.470 --> 00:34:02.759
Herald: OK. What is worse? KAX17 or a well
known trusted operators running 20 percent
00:34:02.759 --> 00:34:06.850
of Tor's exits?
Nusenu: Currently, I would say KAX17.
00:34:06.850 --> 00:34:17.460
Herald: OK. I think that's the last one
for now: Isn't the anonymity, not
00:34:17.460 --> 00:34:22.210
decreased or changed while using trusted
relay list?
00:34:22.210 --> 00:34:27.000
Nusenu: Yes, this is a trade-off that
users will need to make. This heavily
00:34:27.000 --> 00:34:36.860
depends on the threat model.
Herald: OK. So I think we have gathered
00:34:36.860 --> 00:34:42.510
all the questions and they were all
answered. So thank you again for. Yes,
00:34:42.510 --> 00:34:46.225
thank you again.
00:34:46.225 --> 00:34:59.180
rc3 postroll music
00:34:59.180 --> 00:35:03.000
Subtitles created by c3subtitles.de
in the year 2022. Join, and help us!#