1
00:00:00,000 --> 00:00:07,945
intro music
2
00:00:07,945 --> 00:00:13,074
Herald: This is now
"Towards a more trustworthy Tor network"
3
00:00:13,074 --> 00:00:15,109
by Nusenu
4
00:00:15,109 --> 00:00:21,578
The talk will give examples of malicious
relay groups and current issues and how to
5
00:00:21,578 --> 00:00:28,250
tackle those to empower Tor users for
self-defense, so they don't necessarily
6
00:00:28,250 --> 00:00:31,821
need to rely on the detection and removal
of those groups.
7
00:00:31,821 --> 00:00:36,284
So without further ado, enjoy!
8
00:00:36,284 --> 00:00:40,767
And we will see each other
for Q&A afterwards.
9
00:00:45,531 --> 00:00:49,620
Nusenu: Thanks for inviting me to give a
talk about something I deeply care about:
10
00:00:49,620 --> 00:00:51,748
The Tor network.
11
00:00:51,748 --> 00:00:54,273
The Tor network
is a crucial privacy infrastructure,
12
00:00:54,273 --> 00:00:57,338
without which,
we could not use Tor Browser.
13
00:00:57,338 --> 00:01:02,259
I like to uncover malicious Tor relays
to help protect Tor users.
14
00:01:02,259 --> 00:01:06,707
But since that does not come without
personal risks, I'm taking steps
15
00:01:06,707 --> 00:01:10,243
to protect myself from those
running those malicious nodes,
16
00:01:10,243 --> 00:01:12,819
so I can continue to fight them.
17
00:01:12,819 --> 00:01:17,664
For this reason, this is a prerecorded
talk without using my own voice.
18
00:01:18,375 --> 00:01:20,638
Thanks to the people behind the scenes
19
00:01:20,638 --> 00:01:24,770
who made it possible to
present this talk in a safe way.
20
00:01:26,881 --> 00:01:28,875
A few words about me.
21
00:01:28,875 --> 00:01:32,150
I have a long-standing interest
in the state of the Tor network.
22
00:01:32,150 --> 00:01:37,894
In 2015, I started OrNetRadar,
which is a public mailing list and
23
00:01:37,894 --> 00:01:43,481
website showing reports about new
relay groups and possible Sybil attacks.
24
00:01:43,481 --> 00:01:50,176
In 2017, I was asked to join the private
bad-relays Tor Project mailing list
25
00:01:50,176 --> 00:01:55,030
to help analyze and confirm reports
about malicious relays.
26
00:01:56,434 --> 00:02:01,091
To get a better understanding of who runs
what fraction of the Tor network over time
27
00:02:01,091 --> 00:02:07,540
I started OrNetStats. It shows you also
which operators could de-anonymize Tor
28
00:02:07,540 --> 00:02:12,551
users because they are in a position
to perform end-to-end correlation attacks,
29
00:02:12,551 --> 00:02:14,817
something we will describe later.
30
00:02:14,817 --> 00:02:19,919
I'm also the maintainer of
ansible-relayor, which is an Ansible role
31
00:02:19,919 --> 00:02:22,932
used by many large relay operators.
32
00:02:23,410 --> 00:02:27,691
Out of curiosity, I also like
engaging in some limited open-source
33
00:02:27,691 --> 00:02:32,271
intelligence gathering on malicious
Tor network actors, especially when
34
00:02:32,271 --> 00:02:35,761
their motivation for running relays
has not been well understood.
35
00:02:36,601 --> 00:02:39,619
To avoid confusions,
with regards to the Tor Project:
36
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.
37
00:02:47,886 --> 00:02:52,844
In this presentation, we will go through
some examples of malicious actors on
38
00:02:52,844 --> 00:02:58,560
the Tor network. They basically represent
our problem statement that motivates us to
39
00:02:58,560 --> 00:03:04,030
improve the "status quo". After describing
some issues with current approaches to
40
00:03:04,030 --> 00:03:09,060
fight malicious relays, we present a new,
additional approach aiming at achieving a
41
00:03:09,060 --> 00:03:13,738
safer Tor experience using trusted relays
to some extent.
42
00:03:14,757 --> 00:03:17,867
The primary target audience
of this presentation are:
43
00:03:17,867 --> 00:03:24,737
Tor users, like Tor Browser users,
relay operators,
44
00:03:24,737 --> 00:03:29,172
onion service operators
like, for example, SecureDrop
45
00:03:29,172 --> 00:03:33,034
and anyone else that cares about Tor.
46
00:03:35,796 --> 00:03:40,604
To get everyone on the same page,
a quick refresher on how Tor works
47
00:03:40,604 --> 00:03:45,191
and what type of relays – also
called nodes – there are.
48
00:03:45,191 --> 00:03:50,190
When Alice uses Tor Browser
to visit Bob's website,
49
00:03:50,190 --> 00:03:56,014
her Tor client selects three Tor relays
to construct a circuit that will be used
50
00:03:56,014 --> 00:04:00,471
to route her traffic through the
Tor network before it reaches Bob.
51
00:04:00,471 --> 00:04:03,869
This gives Alice location anonymity.
52
00:04:03,869 --> 00:04:08,831
The first relay in such a circuit
is called an entry guard relay.
53
00:04:08,831 --> 00:04:14,803
This relay is the only relay seeing
Alice's real IP address and is therefore
54
00:04:14,803 --> 00:04:20,593
considered a more sensitive type of relay.
The guard relay does not learn that Alice
55
00:04:20,593 --> 00:04:25,740
is connecting to Bob, though. It
only sees the next relay as destination.
56
00:04:25,740 --> 00:04:30,934
Guard relays are not changed frequently,
and Alice's Tor client waits up to 12
57
00:04:30,934 --> 00:04:35,767
weeks before choosing a new guard
to make some attacks less effective.
58
00:04:35,767 --> 00:04:42,397
The second relay is called a middle
or middle only relay. This relay
59
00:04:42,397 --> 00:04:46,960
is the least sensitive position, since it
only sees other relays, but does not know
60
00:04:46,960 --> 00:04:51,136
anything about Alice or Bob because it
just forwards encrypted traffic.
61
00:04:51,601 --> 00:04:56,394
And,
the final relay is called an exit relay.
62
00:04:56,394 --> 00:05:00,992
The exit relay gets to learn the
destination, Bob, but does not know
63
00:05:00,992 --> 00:05:06,200
who is connecting to Bob.
The exit relay is also considered
64
00:05:06,200 --> 00:05:11,350
a more sensitive relay type, since it
potentially gets to see and manipulate
65
00:05:11,350 --> 00:05:20,130
clear text traffic (if Alice is not using
an encrypted protocol like HTTPS.)
66
00:05:20,130 --> 00:05:25,690
Although exit relays see the destination,
they can not link all sites Alice visits
67
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
68
00:05:31,860 --> 00:05:36,310
Tor Browser instructs the Tor client to
create and use distinct circuits for
69
00:05:36,310 --> 00:05:42,930
distinct URL bar domains. So, although
this diagram shows a single circuit only,
70
00:05:42,930 --> 00:05:49,031
a Tor client usually has multiple open Tor
circuits at the same time. In networks
71
00:05:49,031 --> 00:05:56,496
where Tor is censored, users make use of a
special node type, which is called Bridge.
72
00:05:56,496 --> 00:06:01,640
Their primary difference is that they are
not included in the public list of relays,
73
00:06:01,640 --> 00:06:07,190
to make it harder to censor them. Alice
has to manually configure Tor Browser if
74
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
75
00:06:13,280 --> 00:06:16,310
case a bridge goes down or gets censored.
76
00:06:16,310 --> 00:06:22,030
The used bridge also gets to see Alice's
real IP address, but not the destination.
77
00:06:24,676 --> 00:06:28,328
Now that we have a basic
understanding of Tor's design,
78
00:06:28,328 --> 00:06:30,674
we might wonder,
why do we need to trust the network,
79
00:06:30,674 --> 00:06:35,547
when roles are distributed
across multiple relays?
80
00:06:35,547 --> 00:06:38,848
So let's look into some attack scenarios.
81
00:06:40,720 --> 00:06:44,722
If an attacker controls
Alice's guard and exit relay,
82
00:06:44,722 --> 00:06:47,461
they can learn that Alice connected to Bob
83
00:06:47,461 --> 00:06:51,147
by performing
end-to-end correlation attacks.
84
00:06:51,147 --> 00:06:56,559
Such attacks can be passive,
meaning no traffic is manipulated
85
00:06:56,559 --> 00:07:02,111
and therefore cannot be detected by
probing suspect relays with test traffic.
86
00:07:03,203 --> 00:07:09,633
OrNetStats gives you a daily updated list
of potential operators in such a position.
87
00:07:09,633 --> 00:07:15,401
There are some restrictions a default
Tor client follows when building circuits
88
00:07:15,401 --> 00:07:19,019
to reduce the likelihood of this occurring
89
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
90
00:07:24,608 --> 00:07:30,930
network block when building circuits. For
example, Alice's Tor client would never
91
00:07:30,930 --> 00:07:36,430
create this circuit because guard and exit
relays are in the same net block one
92
00:07:36,430 --> 00:07:45,620
192.0./16. For this reason, the number of
distinct /16 network blocks an attacker
93
00:07:45,620 --> 00:07:51,776
distributed its relays across is relevant
when evaluating this kind of risk.
94
00:07:51,776 --> 00:07:59,400
Honest relay operators declare their group
of relays in the so-called "MyFamily"
95
00:07:59,400 --> 00:08:04,639
setting. This way they are transparent
about their set of relays and Tor clients
96
00:08:04,639 --> 00:08:09,090
automatically avoid using more than a
single relay from any given family in a
97
00:08:09,090 --> 00:08:14,770
single circuit. Malicious actors will
either not declare relay families or
98
00:08:14,770 --> 00:08:17,611
pretend to be in more than one family.
99
00:08:19,891 --> 00:08:24,681
Another variant of the end-to-end
correlation attack is possible
100
00:08:24,681 --> 00:08:28,948
when Bob is the attacker or
has been compromised by the attacker,
101
00:08:28,948 --> 00:08:34,871
and the attacker also happens to run
Alice's guard relay. In this case,
102
00:08:34,871 --> 00:08:40,879
the attacker can also determine
the actual source IP address used by Alice
103
00:08:40,879 --> 00:08:43,329
when she visits Bob's website.
104
00:08:45,496 --> 00:08:50,466
In cases of large, suspicious, non-exit
relay groups, it is also plausible that
105
00:08:50,466 --> 00:08:54,406
they are after onion services, because
circuits for onion services do not require
106
00:08:54,406 --> 00:09:01,965
exit relays. Onion services provide
location anonymity to the server side.
107
00:09:01,965 --> 00:09:04,180
By running many non-exits,
108
00:09:04,180 --> 00:09:10,958
an attacker could aim at finding the real
IP address / location of an onion service.
109
00:09:13,037 --> 00:09:17,549
Manipulating exit relays are probably
the most common attack type
110
00:09:17,549 --> 00:09:23,034
detected in the wild. That is also
the easiest-to-perform attack type.
111
00:09:23,034 --> 00:09:29,743
Malicious exits usually do not care who
Alice is or what her actual IP address is.
112
00:09:29,743 --> 00:09:34,503
They are mainly interested to
profit from traffic manipulation.
113
00:09:35,488 --> 00:09:40,737
This type of attack can be detected
by probing exits with decoy traffic,
114
00:09:40,737 --> 00:09:45,159
but since malicious exits moved
to more targeted approaches
115
00:09:45,159 --> 00:09:50,182
(specific domains only), detection
is less trivial than one might think.
116
00:09:51,380 --> 00:09:56,071
The best protection against this
kind of attack is using encryption.
117
00:09:56,071 --> 00:10:00,999
Malicious exit relays cannot harm
connections going to onion services.
118
00:10:02,892 --> 00:10:06,629
Now, let's look into
two real-world examples
119
00:10:06,629 --> 00:10:10,474
of large scale and persistent
malicious actors on the Tor network.
120
00:10:12,507 --> 00:10:20,060
The first example, tracked as BTCMITM20,
is in the malicious exit's business and
121
00:10:20,060 --> 00:10:26,980
performs SSL strip attacks on exit relays
to manipulate plaintext HTTP traffic,
122
00:10:26,980 --> 00:10:31,901
like Bitcoin addresses,
to divert Bitcoin transactions to them.
123
00:10:31,901 --> 00:10:37,981
They have been detected for the first time
in 2020, and had some pretty large relay
124
00:10:37,981 --> 00:10:44,332
groups. On this graph, you can see how
much of the Tor exit fraction was under
125
00:10:44,332 --> 00:10:50,230
their control in the first half of 2020.
The different colors represent different
126
00:10:50,230 --> 00:10:56,248
contact infos they gave on their relays
to pretend they are distinct groups.
127
00:10:56,248 --> 00:11:00,026
The sharp drops show events when
they were removed from the network,
128
00:11:00,026 --> 00:11:02,661
before adding relays again.
129
00:11:03,968 --> 00:11:11,647
In February 2021, they managed over 27%
of the Tor network's exit capacity,
130
00:11:11,647 --> 00:11:15,838
despite multiple removal attempts
over almost a year.
131
00:11:16,721 --> 00:11:23,143
At some point in the future,
we will hopefully have HTTPS-Only mode
132
00:11:23,143 --> 00:11:28,449
enabled by default in Tor Browser
to kill this entire attack vector for good
133
00:11:28,449 --> 00:11:32,203
and make malicious exits less lucrative.
134
00:11:32,203 --> 00:11:37,242
I encourage you to test
HTTPS-Only mode in Tor Browser
135
00:11:37,242 --> 00:11:42,135
and notify website operators
that do not work in that mode.
136
00:11:42,135 --> 00:11:45,586
If a website does not work
in HTTPS-Only mode,
137
00:11:45,586 --> 00:11:50,078
you also know it is probably
not safe to use in the first place.
138
00:11:51,806 --> 00:11:57,106
The second example actor,
tracked as KAX17,
139
00:11:57,106 --> 00:12:02,728
is still somewhat of a mystery. And
that is not the best situation to be in.
140
00:12:02,728 --> 00:12:07,032
They are remarkable for:
their focus on non-exit relays,
141
00:12:07,032 --> 00:12:13,036
their network diversity,
with over 200 distinct /16 subnets,
142
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
143
00:12:19,432 --> 00:12:25,684
advertised non-exit bandwidth – and
they are active since a very long time.
144
00:12:27,422 --> 00:12:32,059
Let's have a look at some KAX17
related events in the past two years.
145
00:12:32,059 --> 00:12:38,856
I first detected and reported them
to the Tor Project in September 2019.
146
00:12:38,856 --> 00:12:44,084
In October 2019,
KAX17 relays got removed
147
00:12:44,084 --> 00:12:47,459
by the Tor directory
authorities for the first time.
148
00:12:49,756 --> 00:12:54,212
In December 2019,
I published the first blog post about them
149
00:12:54,212 --> 00:12:57,783
At that point, they were already
rebuilding their infrastructure
150
00:12:57,783 --> 00:13:00,576
by adding new relays.
151
00:13:01,827 --> 00:13:07,791
In February 2020, I contacted an email
address that was used on some relays that
152
00:13:07,791 --> 00:13:13,339
did not properly declare their relay group
using the "MyFamily" setting. At the time,
153
00:13:13,339 --> 00:13:18,640
they said they would run bridges instead,
so they do not have to set MyFamily.
154
00:13:18,640 --> 00:13:23,814
Side note:
MyFamily is not supported for bridges.
155
00:13:23,814 --> 00:13:30,292
I was not aware that this email address
is linked to KAX17 until October 2021.
156
00:13:31,208 --> 00:13:37,709
In the first half of 2020,
I regularly reported large quantities of
157
00:13:37,709 --> 00:13:43,914
relays to the Tor Project, and they got
removed at high pace until June 2020,
158
00:13:43,914 --> 00:13:48,444
when directory authorities changed their
practices and stopped removing them
159
00:13:48,444 --> 00:13:53,600
because they didn't want to "scare away"
potential new relay operators.
160
00:13:54,859 --> 00:13:58,524
In July 2020, an email address joined
a tor-relays mailing list discussion
161
00:13:58,524 --> 00:14:07,178
I started about a proposal to limit
large-scale attacks on the network.
162
00:14:07,178 --> 00:14:12,725
Now we know
that email address is linked to KAX17.
163
00:14:13,920 --> 00:14:18,445
Since the Tor directory authorities
no longer removed the relay groups
164
00:14:18,445 --> 00:14:24,090
showing up, I sent the information
of over 600 KAX17 relays
165
00:14:24,090 --> 00:14:26,518
to the public tor-talk mailing list.
166
00:14:27,703 --> 00:14:32,321
In October 2021, someone who asked for
anonymity reached out to me and provided a
167
00:14:32,321 --> 00:14:39,287
new way to detect Tor relay groups that
do not run the official Tor software.
168
00:14:40,518 --> 00:14:45,351
Using this methodology,
we were able to detect KAX17
169
00:14:45,351 --> 00:14:47,722
using a second detection method.
170
00:14:47,722 --> 00:14:52,224
This also apparently convinced
the Tor directory authorities,
171
00:14:52,224 --> 00:14:57,095
and in November this year,
a major removal event took place.
172
00:14:58,530 --> 00:15:03,889
Sadly, the time span during which
KAX17 was running relays without
173
00:15:03,889 --> 00:15:11,480
limitations was rather long.
This motivated us to come up with a
174
00:15:11,480 --> 00:15:16,598
design that avoids this kind of complete
dependency on Tor directory authorities
175
00:15:16,598 --> 00:15:19,262
when it comes to safety issues.
176
00:15:20,032 --> 00:15:22,810
And, as you might guess,
177
00:15:22,810 --> 00:15:27,372
KAX17 is already attempting
to restore their foothold again.
178
00:15:30,009 --> 00:15:33,404
Here are some KAX17 properties.
179
00:15:33,404 --> 00:15:39,502
After the release of my second
KAX17 blog post in November 2021,
180
00:15:39,502 --> 00:15:43,819
the media was quick with using
words like "nation-state" and
181
00:15:43,819 --> 00:15:46,860
"Advanced Persistent Threat".
182
00:15:46,860 --> 00:15:53,175
But I find it hard to believe such such
serious entities would be so sloppy.
183
00:15:53,175 --> 00:15:58,061
Since they claim to work for an ISP
in every other email…
184
00:15:58,797 --> 00:16:02,144
I looked into their AS distribution.
185
00:16:02,800 --> 00:16:06,881
I guess they work for more than one ISP.
186
00:16:07,686 --> 00:16:10,625
This chart shows used Autonomous System,
187
00:16:10,625 --> 00:16:15,972
sorted by the unique IP addresses
used at that hoster. So, for example,
188
00:16:15,972 --> 00:16:21,178
They used more than 400 IP
addresses at Microsoft to run relays.
189
00:16:21,178 --> 00:16:27,009
These are not exact numbers,
since it only includes relays since 2019,
190
00:16:27,009 --> 00:16:33,019
and there are likely more.
If we map their IP addresses
191
00:16:33,019 --> 00:16:39,050
to countries, we get this. Do not take
this map too seriously, as the used GEOIP
192
00:16:39,050 --> 00:16:44,819
database was severely outdated and such
databases are never completely accurate,
193
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
194
00:16:54,980 --> 00:17:00,670
performing any kind of attacks against Tor
users, but in our threat model it is
195
00:17:00,670 --> 00:17:06,069
already a considerable risk if even a
benevolent operator is not declaring their
196
00:17:06,069 --> 00:17:12,039
more than 800 relays as a family. Good
protections should protect against
197
00:17:12,039 --> 00:17:17,809
benevolent and malicious Sybil attacks
equally. The strongest input factor for
198
00:17:17,809 --> 00:17:23,240
the risk assessment of this actor is the
fact they do not run the official Tor
199
00:17:23,240 --> 00:17:28,769
software on their relays. There are still
many open questions, and the analysis into
200
00:17:28,769 --> 00:17:39,370
KAX17 is ongoing. If you have any input,
feel free to reach out to me. After
201
00:17:39,370 --> 00:17:44,419
looking at some examples of malicious
actors, I want to shortly summarize some
202
00:17:44,419 --> 00:17:51,519
of the issues in how the malicious relays
problem is currently approached. It is
203
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
204
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
205
00:18:02,620 --> 00:18:08,580
training them to come back stronger next
time. Malicious actors can run relays
206
00:18:08,580 --> 00:18:14,669
until they get caught/detected or are
considered suspicious enough for removal
207
00:18:14,669 --> 00:18:20,630
by a Tor directory authorities. If your
threat model does not match the Tor
208
00:18:20,630 --> 00:18:25,179
directory's threat model, you are out of
luck or have to maintain your own
209
00:18:25,179 --> 00:18:31,370
exclusion lists. Attempts to define a
former set of "do not do" requirements for
210
00:18:31,370 --> 00:18:36,991
relays that Tor directory authorities
commit to enforce, have failed, even with
211
00:18:36,991 --> 00:18:45,760
the involvement of a core Tor developer.
It is time for a paradigm change. The
212
00:18:45,760 --> 00:18:50,799
current processes for detecting and
removing malicious Tor relays are failing
213
00:18:50,799 --> 00:18:56,660
us and are not sustainable in the long
run. In recent years, malicious groups
214
00:18:56,660 --> 00:19:05,660
have become larger, harder to detect,
harder to get removed and more persistent.
215
00:19:05,660 --> 00:19:11,970
Here are some of our design goals. Instead
of continuing the single sided arms race
216
00:19:11,970 --> 00:19:17,389
with malicious actors. We aim to empower
Tor users for self-defense without
217
00:19:17,389 --> 00:19:22,260
requiring the detection of malicious Tor
relays and without, solely, depending on
218
00:19:22,260 --> 00:19:28,389
Tor directly authorities for protecting us
from malicious relays. We aim to reduce
219
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
220
00:19:36,899 --> 00:19:41,440
also acknowledge it is increasingly
impossible to detect all malicious relays
221
00:19:41,440 --> 00:19:46,990
using decoy traffic, therefore, we stop
depending on the detectability of
222
00:19:46,990 --> 00:19:56,270
malicious relays to protect users. In
today's Tor network, we hope to not choose
223
00:19:56,270 --> 00:20:01,519
a malicious guard when we pick one. In the
proposed design, we would pick a trusted
224
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
225
00:20:07,620 --> 00:20:14,289
trusted relays as your bridge. Another
supported configuration would be to use
226
00:20:14,289 --> 00:20:20,169
trusted guards and trusted exits. Such
designs are possible without requiring
227
00:20:20,169 --> 00:20:25,370
code changes in Tor, but are cumbersome to
configure manually, since Tor only
228
00:20:25,370 --> 00:20:33,310
supports relay fingerprints and does not
know about relay operator identifiers. But
229
00:20:33,310 --> 00:20:39,460
what do we actually mean by trusted
relays? Trusted relays are operated by
230
00:20:39,460 --> 00:20:45,380
trusted operators. These operators are
believed to run relays without malicious
231
00:20:45,380 --> 00:20:51,559
intent. Trusted operators are specified by
the user. Users assign trust at the
232
00:20:51,559 --> 00:20:57,450
operator, not the relay level, for
scalability reasons, and to avoid
233
00:20:57,450 --> 00:21:05,990
configuration changes when an operator
changes their relays. Since users should
234
00:21:05,990 --> 00:21:12,100
be able to specify trusted operators, we
need human-readable, authenticated and
235
00:21:12,100 --> 00:21:19,029
globally unique operator identifiers. By
authenticated, we mean they should not be
236
00:21:19,029 --> 00:21:26,700
spoofable arbitrarily like current relay
contact infos. For simplicity, we use DNS
237
00:21:26,700 --> 00:21:34,140
domains as relay operator identifiers, and
we will probably restrict them to 40
238
00:21:34,140 --> 00:21:47,000
characters in length. How do Authenticated
Relay Operator IDs, short AROI, work. From
239
00:21:47,000 --> 00:21:52,490
an operator point of view, configuring an
AROI is easy. Step one: The operator
240
00:21:52,490 --> 00:21:59,559
specifies the desired domain under her
control using Tor's ContactInfo option.
241
00:21:59,559 --> 00:22:06,850
Step two: The operator publishes a simple
text file using the IANA well-known URI
242
00:22:06,850 --> 00:22:13,100
containing all relay fingerprints. If no
web server is available or if the web
243
00:22:13,100 --> 00:22:18,710
server is not considered safe enough,
DNSSEC-signed TXT records are also an
244
00:22:18,710 --> 00:22:25,580
option for authentication. Using DNS is
great for scalability and availability due
245
00:22:25,580 --> 00:22:31,299
to DNS caching, but since every relay
requires its own TXT record, it will take
246
00:22:31,299 --> 00:22:37,110
longer than the URI type proof when
performing proof validation. Operators
247
00:22:37,110 --> 00:22:42,370
that have no domain at all can use free
services like GitHub pages or similar to
248
00:22:42,370 --> 00:22:49,870
serve the text file. For convenience, Eran
Sandler created this simple to use
249
00:22:49,870 --> 00:22:55,100
ContactInfo generator, so relay operators
don't have to read the specification to
250
00:22:55,100 --> 00:23:00,530
generate the required ContactInfo string
for their configuration. For the
251
00:23:00,530 --> 00:23:06,290
Authenticated Relay Operator ID the "url"
and "proof" fields are the only relevant
252
00:23:06,290 --> 00:23:13,720
fields. There are already over 1000 relays
that have implemented the Authenticated
253
00:23:13,720 --> 00:23:21,690
Relay Operator ID. OrNetStats displays an
icon in case the operator implemented it
254
00:23:21,690 --> 00:23:29,110
correctly. Out of the top 24 largest
families by bandwidth, all but eight
255
00:23:29,110 --> 00:23:34,720
operators have implemented the
Authenticated Relay Operator ID already.
256
00:23:34,720 --> 00:23:40,380
On the right-hand side, you can see a few
logos of organizations running relays with
257
00:23:40,380 --> 00:23:46,639
a properly set up AROI. The most relevant
distinction between lines having that
258
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
259
00:23:51,790 --> 00:23:59,409
that do not include the icon can be
arbitrarily spoofed. This graph shows the
260
00:23:59,409 --> 00:24:05,549
largest exit operators that implemented
the AROI. I want to stress one crucial
261
00:24:05,549 --> 00:24:12,660
point about AROIs though, authenticated
must not be confused with trusted.
262
00:24:12,660 --> 00:24:19,200
Malicious operators can also authenticate
their domain and they do. A given AROI can
263
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
264
00:24:25,529 --> 00:24:30,669
assigning trust is crucial because
ContactInfo can not be trusted directly
265
00:24:30,669 --> 00:24:37,840
without further checks. This graph shows
what fraction of the Tor network's exit
266
00:24:37,840 --> 00:24:43,769
capacity implemented the Authenticated
Relay Operator ID over time. Currently, we
267
00:24:43,769 --> 00:24:49,529
are at around 60 percent already, but
guard capacity is a lot lower, around 15
268
00:24:49,529 --> 00:24:55,880
percent. The reason for that is that exits
are operated mostly by large operators and
269
00:24:55,880 --> 00:25:00,909
organizations, while guards are
distributed across a lot more operators.
270
00:25:00,909 --> 00:25:11,450
There are over 1800 guard families, but
only around 400 exit families. How does a
271
00:25:11,450 --> 00:25:19,380
Tor client make use of AROIs, current Tor
versions do not know what AROIs are and
272
00:25:19,380 --> 00:25:24,690
primarily take relay fingerprints as
configuration inputs. So, we need some
273
00:25:24,690 --> 00:25:28,980
tooling to generate a list of relay
fingerprints starting from a list of
274
00:25:28,980 --> 00:25:36,919
trusted AROIs. We have implemented a quick
and dirty proof of concept that puts
275
00:25:36,919 --> 00:25:41,370
everything together and performs all the
steps shown on this slide, to demonstrate
276
00:25:41,370 --> 00:25:47,100
the concept of using trusted AROIs to
configure Tor client to use trusted exit
277
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
278
00:25:53,639 --> 00:25:57,570
technical audience who would like to see
it in action to achieve a better
279
00:25:57,570 --> 00:26:03,870
understanding of the design. The current
proof of concept performs all proof checks
280
00:26:03,870 --> 00:26:09,799
itself without relying on third parties,
but since there are a lot of reasons for
281
00:26:09,799 --> 00:26:15,080
doing proof-checks centrally instead, for
example, by directory authorities. I
282
00:26:15,080 --> 00:26:21,080
recently submitted a partial proposal for
it to the Tor development mailing list to
283
00:26:21,080 --> 00:26:25,080
see whether they would consider it before
proceeding with a more serious
284
00:26:25,080 --> 00:26:30,950
implementation than the current proof of
concept. I find it important to always try
285
00:26:30,950 --> 00:26:35,820
achieving a common goal together with
upstream first before creating solutions
286
00:26:35,820 --> 00:26:40,769
that are maintained outside of upstream
because it will lead to better maintained
287
00:26:40,769 --> 00:26:46,179
improvements and likely a more user-
friendly experience if they are integrated
288
00:26:46,179 --> 00:26:52,909
in upstream. Here is a link to the
mentioned tor-dev email, for those who
289
00:26:52,909 --> 00:27:01,789
would like to follow along. To summarize,
after reviewing some real world examples
290
00:27:01,789 --> 00:27:08,200
of malicious actors on the Tor network, we
concluded that current approaches to limit
291
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
292
00:27:16,269 --> 00:27:22,490
sustainable in the long run and need an
upgrade to avoid depending on the
293
00:27:22,490 --> 00:27:28,610
detectability of malicious relays, which
is becoming increasingly hard. We
294
00:27:28,610 --> 00:27:34,909
presented a design to extend current anti
bad relay approaches that does not rely on
295
00:27:34,909 --> 00:27:41,340
the detection of malicious relays using
trusted Authenticated Relay Operator IDs.
296
00:27:41,340 --> 00:27:47,080
We have shown that most exit capacity has
implemented AROIs already, while guard
297
00:27:47,080 --> 00:27:53,289
capacity is currently significantly lower,
showing a lack of insights on who operates
298
00:27:53,289 --> 00:28:00,100
Tor's guard capacity. When publicly
speaking about modifying Tor's path
299
00:28:00,100 --> 00:28:06,590
selection in front of a wide audience, I
also consider it to be my responsibility
300
00:28:06,590 --> 00:28:12,759
to explicitly state that you should not
change your Tor configuration options that
301
00:28:12,759 --> 00:28:18,380
influenced path selection behavior without
a clear need, according to your threat
302
00:28:18,380 --> 00:28:26,230
model to avoid potentially standing out.
Using trusted AROIs certainly comes with
303
00:28:26,230 --> 00:28:31,990
some tradeoffs of its own, like for
example, network load balancing, to name
304
00:28:31,990 --> 00:28:38,570
only one. Thanks to many large, trusted
exit operators, it should be feasible in
305
00:28:38,570 --> 00:28:43,090
the near future to use trusted exits
without standing out in a trivially
306
00:28:43,090 --> 00:28:49,259
detectable way because it is harder in the
sense of takes longer to statistically
307
00:28:49,259 --> 00:28:55,110
detect a Tor client changed its possible
pool of exits, if it only excluded a
308
00:28:55,110 --> 00:29:02,519
smaller fraction of exits. Detecting Tor
clients using only a subset of all guards
309
00:29:02,519 --> 00:29:08,539
takes a lot longer than detecting custom
exit sets because guards are not changed
310
00:29:08,539 --> 00:29:16,120
over a longer period of time when compared
with exits. And finally, Tor clients that
311
00:29:16,120 --> 00:29:22,860
make use of trusted AROIs will need a way
to find trusted AROIs, ideally, they could
312
00:29:22,860 --> 00:29:29,789
learn about them dynamically in a safe
way. There is an early work in progress
313
00:29:29,789 --> 00:29:40,399
draft specification linked on this slide.
I want to dedicate this talk to Karsten
314
00:29:40,399 --> 00:29:47,309
Loesing who passed away last year. He was
the kindest person I got to interact with
315
00:29:47,309 --> 00:29:54,059
in the Tor community. Karsten was the Tor
metrics team lead and without his work, my
316
00:29:54,059 --> 00:29:59,830
projects, OrNetStats and OrNetRadar would
not exist. Every time you use
317
00:29:59,830 --> 00:30:07,389
metrics.torproject.org, for example, the
so-called "Relay Search", you are using
318
00:30:07,389 --> 00:30:14,730
his legacy. Thank you for listening, and
I'm really looking forward to your
319
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
320
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
321
00:30:23,980 --> 00:30:28,659
recording and I'll make an effort to
publish answers to all of them via
322
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
323
00:30:35,679 --> 00:30:40,720
about unusual things you observed on the
Tor network. Do not underestimate your
324
00:30:40,720 --> 00:30:48,200
power as Tor user to contribute to a safer
Tor network by reporting unusual things.
325
00:30:48,200 --> 00:30:55,050
Most major hits against bad relay actors
were the result of Tor user reports.
326
00:30:55,050 --> 00:31:18,540
quietness
327
00:31:18,540 --> 00:31:27,809
Herald: OK. Thank you very much for this
very informative talk and yes so we will
328
00:31:27,809 --> 00:31:41,059
switch over to the Q&A now. Yeah, thanks
again. Very fascinating. So we have
329
00:31:41,059 --> 00:31:50,609
collected several questions from our IRC
chat, so I'm just going to start. If
330
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
331
00:31:57,270 --> 00:32:03,840
correlation attacks, for example if a
malicious actor can somehow make the relay
332
00:32:03,840 --> 00:32:10,179
popular as bridge?
Nusenu: Yes, bridges are a concern in the
333
00:32:10,179 --> 00:32:15,419
context of MyFamily, for that reason, it
is not recommended to run bridges and
334
00:32:15,419 --> 00:32:20,200
exits at the same time in current versions
of Tor, but future versions of Tor will
335
00:32:20,200 --> 00:32:26,200
get a new and more relay operator friendly
MyFamily setting. That new MyFamily design
336
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
337
00:32:33,539 --> 00:32:45,110
2022.
Herald: OK, thanks. Despite what kind of
338
00:32:45,110 --> 00:32:55,120
attack, are there statistics who or from
which country these attacks are coming
339
00:32:55,120 --> 00:33:02,799
most? Background here is there are rumors
about NSA driven and exit notes.
340
00:33:02,799 --> 00:33:08,389
Nusenu: I don't know about any general
statistics, but I usually include used
341
00:33:08,389 --> 00:33:13,610
autonomous systems by certain groups when
blogging about them. There are some
342
00:33:13,610 --> 00:33:17,899
autonomous systems that are notorious for
being used by malicious groups, but
343
00:33:17,899 --> 00:33:23,200
malicious groups also try to blend in with
the rest by using large ISPs like Hetzner
344
00:33:23,200 --> 00:33:30,750
and OVH.
Herald: Thanks. Is using a bridge that I
345
00:33:30,750 --> 00:33:35,009
host also safer than using a random guard
node?
346
00:33:35,009 --> 00:33:41,790
Nusenu: This is a tricky question, since
it also depends on whether it is a private
347
00:33:41,790 --> 00:33:47,380
bridge, a bridge that is not distributed
to other uses by a bridgeDB. I would say
348
00:33:47,380 --> 00:33:53,470
it is better to not run the bridges you
use yourself.
349
00:33:53,470 --> 00:34:02,759
Herald: OK. What is worse? KAX17 or a well
known trusted operators running 20 percent
350
00:34:02,759 --> 00:34:06,850
of Tor's exits?
Nusenu: Currently, I would say KAX17.
351
00:34:06,850 --> 00:34:17,460
Herald: OK. I think that's the last one
for now: Isn't the anonymity, not
352
00:34:17,460 --> 00:34:22,210
decreased or changed while using trusted
relay list?
353
00:34:22,210 --> 00:34:27,000
Nusenu: Yes, this is a trade-off that
users will need to make. This heavily
354
00:34:27,000 --> 00:34:36,860
depends on the threat model.
Herald: OK. So I think we have gathered
355
00:34:36,860 --> 00:34:42,510
all the questions and they were all
answered. So thank you again for. Yes,
356
00:34:42,510 --> 00:34:46,225
thank you again.
357
00:34:46,225 --> 00:34:59,180
rc3 postroll music
358
00:34:59,180 --> 00:35:03,000
Subtitles created by c3subtitles.de
in the year 2022. Join, and help us!#