0:00:00.000,0:00:07.945
<i>intro music</i>

0:00:07.945,0:00:13.074
Herald: This is now [br]"Towards a more trustworthy Tor network"

0:00:13.074,0:00:15.109
by Nusenu

0:00:15.109,0:00:21.578
The talk will give examples of malicious[br]relay groups and current issues and how to

0:00:21.578,0:00:28.250
tackle those to empower Tor users for[br]self-defense, so they don't necessarily

0:00:28.250,0:00:31.821
need to rely on the detection and removal[br]of those groups.

0:00:31.821,0:00:36.284
So without further ado, enjoy!

0:00:36.284,0:00:40.767
And we will see each other [br]for Q&amp;A afterwards.

0:00:45.531,0:00:49.620
Nusenu: Thanks for inviting me to give a[br]talk about something I deeply care about:

0:00:49.620,0:00:51.748
The Tor network.

0:00:51.748,0:00:54.273
The Tor network [br]is a crucial privacy infrastructure,

0:00:54.273,0:00:57.338
without which, [br]we could not use Tor Browser.

0:00:57.338,0:01:02.259
I like to uncover malicious Tor relays [br]to help protect Tor users.

0:01:02.259,0:01:06.707
But since that does not come without [br]personal risks, I'm taking steps

0:01:06.707,0:01:10.243
to protect myself from those [br]running those malicious nodes,

0:01:10.243,0:01:12.819
so I can continue to fight them.

0:01:12.819,0:01:17.664
For this reason, this is a prerecorded [br]talk without using my own voice.

0:01:18.375,0:01:20.638
Thanks to the people behind the scenes

0:01:20.638,0:01:24.770
who made it possible to [br]present this talk in a safe way.

0:01:26.881,0:01:28.875
A few words about me.

0:01:28.875,0:01:32.150
I have a long-standing interest [br]in the state of the Tor network.

0:01:32.150,0:01:37.894
In 2015, I started OrNetRadar, [br]which is a public mailing list and

0:01:37.894,0:01:43.481
website showing reports about new[br]relay groups and possible Sybil attacks.

0:01:43.481,0:01:50.176
In 2017, I was asked to join the private [br]bad-relays Tor Project mailing list

0:01:50.176,0:01:55.030
to help analyze and confirm reports[br]about malicious relays.

0:01:56.434,0:02:01.091
To get a better understanding of who runs[br]what fraction of the Tor network over time

0:02:01.091,0:02:07.540
I started OrNetStats. It shows you also[br]which operators could de-anonymize Tor

0:02:07.540,0:02:12.551
users because they are in a position [br]to perform end-to-end correlation attacks,

0:02:12.551,0:02:14.817
something we will describe later.

0:02:14.817,0:02:19.919
I'm also the maintainer of [br]ansible-relayor, which is an Ansible role

0:02:19.919,0:02:22.932
used by many large relay operators.

0:02:23.410,0:02:27.691
Out of curiosity, I also like[br]engaging in some limited open-source

0:02:27.691,0:02:32.271
intelligence gathering on malicious [br]Tor network actors, especially when

0:02:32.271,0:02:35.761
their motivation for running relays [br]has not been well understood.

0:02:36.601,0:02:39.619
To avoid confusions, [br]with regards to the Tor Project:

0:02:39.619,0:02:45.015
I am not employed by the Tor Project [br]and I do not speak for the Tor Project.

0:02:47.886,0:02:52.844
In this presentation, we will go through[br]some examples of malicious actors on

0:02:52.844,0:02:58.560
the Tor network. They basically represent[br]our problem statement that motivates us to

0:02:58.560,0:03:04.030
improve the "status quo". After describing[br]some issues with current approaches to

0:03:04.030,0:03:09.060
fight malicious relays, we present a new,[br]additional approach aiming at achieving a

0:03:09.060,0:03:13.738
safer Tor experience using trusted relays[br]to some extent.

0:03:14.757,0:03:17.867
The primary target audience [br]of this presentation are:

0:03:17.867,0:03:24.737
Tor users, like Tor Browser users, [br]relay operators,

0:03:24.737,0:03:29.172
onion service operators [br]like, for example, SecureDrop

0:03:29.172,0:03:33.034
and anyone else that cares about Tor.

0:03:35.796,0:03:40.604
To get everyone on the same page, [br]a quick refresher on how Tor works

0:03:40.604,0:03:45.191
and what type of relays – also[br]called nodes – there are.

0:03:45.191,0:03:50.190
When Alice uses Tor Browser [br]to visit Bob's website,

0:03:50.190,0:03:56.014
her Tor client selects three Tor relays [br]to construct a circuit that will be used

0:03:56.014,0:04:00.471
to route her traffic through the [br]Tor network before it reaches Bob.

0:04:00.471,0:04:03.869
This gives Alice location anonymity.

0:04:03.869,0:04:08.831
The first relay in such a circuit [br]is called an entry guard relay.

0:04:08.831,0:04:14.803
This relay is the only relay seeing [br]Alice's real IP address and is therefore

0:04:14.803,0:04:20.593
considered a more sensitive type of relay. [br]The guard relay does not learn that Alice

0:04:20.593,0:04:25.740
is connecting to Bob, though. It [br]only sees the next relay as destination.

0:04:25.740,0:04:30.934
Guard relays are not changed frequently,[br]and Alice's Tor client waits up to 12

0:04:30.934,0:04:35.767
weeks before choosing a new guard [br]to make some attacks less effective.

0:04:35.767,0:04:42.397
The second relay is called a middle [br]or middle only relay. This relay

0:04:42.397,0:04:46.960
is the least sensitive position, since it[br]only sees other relays, but does not know

0:04:46.960,0:04:51.136
anything about Alice or Bob because it[br]just forwards encrypted traffic.

0:04:51.601,0:04:56.394
And, [br]the final relay is called an exit relay.

0:04:56.394,0:05:00.992
The exit relay gets to learn the [br]destination, Bob, but does not know

0:05:00.992,0:05:06.200
who is connecting to Bob. [br]The exit relay is also considered

0:05:06.200,0:05:11.350
a more sensitive relay type, since it[br]potentially gets to see and manipulate

0:05:11.350,0:05:20.130
clear text traffic (if Alice is not using[br]an encrypted protocol like HTTPS.)

0:05:20.130,0:05:25.690
Although exit relays see the destination,[br]they can not link all sites Alice visits

0:05:25.690,0:05:31.860
at a given point in time to the same Tor[br]client, to profile her, because Alice's

0:05:31.860,0:05:36.310
Tor Browser instructs the Tor client to[br]create and use distinct circuits for

0:05:36.310,0:05:42.930
distinct URL bar domains. So, although[br]this diagram shows a single circuit only,

0:05:42.930,0:05:49.031
a Tor client usually has multiple open Tor[br]circuits at the same time. In networks

0:05:49.031,0:05:56.496
where Tor is censored, users make use of a[br]special node type, which is called Bridge.

0:05:56.496,0:06:01.640
Their primary difference is that they are[br]not included in the public list of relays,

0:06:01.640,0:06:07.190
to make it harder to censor them. Alice[br]has to manually configure Tor Browser if

0:06:07.190,0:06:13.280
she wants to use a bridge. For redundancy,[br]it is good to have more than one bridge in

0:06:13.280,0:06:16.310
case a bridge goes down or gets censored.

0:06:16.310,0:06:22.030
The used bridge also gets to see Alice's [br]real IP address, but not the destination.

0:06:24.676,0:06:28.328
Now that we have a basic [br]understanding of Tor's design,

0:06:28.328,0:06:30.674
we might wonder,[br]why do we need to trust the network,

0:06:30.674,0:06:35.547
when roles are distributed [br]across multiple relays?

0:06:35.547,0:06:38.848
So let's look into some attack scenarios.

0:06:40.720,0:06:44.722
If an attacker controls [br]Alice's guard and exit relay,

0:06:44.722,0:06:47.461
they can learn that Alice connected to Bob

0:06:47.461,0:06:51.147
by performing [br]end-to-end correlation attacks.

0:06:51.147,0:06:56.559
Such attacks can be passive, [br]meaning no traffic is manipulated

0:06:56.559,0:07:02.111
and therefore cannot be detected by [br]probing suspect relays with test traffic.

0:07:03.203,0:07:09.633
OrNetStats gives you a daily updated list [br]of potential operators in such a position.

0:07:09.633,0:07:15.401
There are some restrictions a default[br]Tor client follows when building circuits

0:07:15.401,0:07:19.019
to reduce the likelihood of this occurring

0:07:19.019,0:07:24.608
For example, a Tor client does not use[br]more than one relay in the same /16 IPv4

0:07:24.608,0:07:30.930
network block when building circuits. For[br]example, Alice's Tor client would never

0:07:30.930,0:07:36.430
create this circuit because guard and exit[br]relays are in the same net block one

0:07:36.430,0:07:45.620
192.0./16. For this reason, the number of[br]distinct /16 network blocks an attacker

0:07:45.620,0:07:51.776
distributed its relays across is relevant[br]when evaluating this kind of risk.

0:07:51.776,0:07:59.400
Honest relay operators declare their group[br]of relays in the so-called "MyFamily"

0:07:59.400,0:08:04.639
setting. This way they are transparent[br]about their set of relays and Tor clients

0:08:04.639,0:08:09.090
automatically avoid using more than a[br]single relay from any given family in a

0:08:09.090,0:08:14.770
single circuit. Malicious actors will[br]either not declare relay families or

0:08:14.770,0:08:17.611
pretend to be in more than one family.

0:08:19.891,0:08:24.681
Another variant of the end-to-end [br]correlation attack is possible

0:08:24.681,0:08:28.948
when Bob is the attacker or [br]has been compromised by the attacker,

0:08:28.948,0:08:34.871
and the attacker also happens to run [br]Alice's guard relay. In this case,

0:08:34.871,0:08:40.879
the attacker can also determine[br]the actual source IP address used by Alice

0:08:40.879,0:08:43.329
when she visits Bob's website.

0:08:45.496,0:08:50.466
In cases of large, suspicious, non-exit [br]relay groups, it is also plausible that

0:08:50.466,0:08:54.406
they are after onion services, because [br]circuits for onion services do not require

0:08:54.406,0:09:01.965
exit relays. Onion services provide [br]location anonymity to the server side.

0:09:01.965,0:09:04.180
By running many non-exits,

0:09:04.180,0:09:10.958
an attacker could aim at finding the real[br]IP address / location of an onion service.

0:09:13.037,0:09:17.549
Manipulating exit relays are probably[br]the most common attack type

0:09:17.549,0:09:23.034
detected in the wild. That is also[br]the easiest-to-perform attack type.

0:09:23.034,0:09:29.743
Malicious exits usually do not care who[br]Alice is or what her actual IP address is.

0:09:29.743,0:09:34.503
They are mainly interested to [br]profit from traffic manipulation.

0:09:35.488,0:09:40.737
This type of attack can be detected [br]by probing exits with decoy traffic,

0:09:40.737,0:09:45.159
but since malicious exits moved [br]to more targeted approaches

0:09:45.159,0:09:50.182
(specific domains only), detection [br]is less trivial than one might think.

0:09:51.380,0:09:56.071
The best protection against this [br]kind of attack is using encryption.

0:09:56.071,0:10:00.999
Malicious exit relays cannot harm [br]connections going to onion services.

0:10:02.892,0:10:06.629
Now, let's look into [br]two real-world examples

0:10:06.629,0:10:10.474
of large scale and persistent [br]malicious actors on the Tor network.

0:10:12.507,0:10:20.060
The first example, tracked as BTCMITM20,[br]is in the malicious exit's business and

0:10:20.060,0:10:26.980
performs SSL strip attacks on exit relays [br]to manipulate plaintext HTTP traffic,

0:10:26.980,0:10:31.901
like Bitcoin addresses,[br]to divert Bitcoin transactions to them.

0:10:31.901,0:10:37.981
They have been detected for the first time[br]in 2020, and had some pretty large relay

0:10:37.981,0:10:44.332
groups. On this graph, you can see how [br]much of the Tor exit fraction was under

0:10:44.332,0:10:50.230
their control in the first half of 2020. [br]The different colors represent different

0:10:50.230,0:10:56.248
contact infos they gave on their relays [br]to pretend they are distinct groups.

0:10:56.248,0:11:00.026
The sharp drops show events when [br]they were removed from the network,

0:11:00.026,0:11:02.661
before adding relays again.

0:11:03.968,0:11:11.647
In February 2021, they managed over 27% [br]of the Tor network's exit capacity,

0:11:11.647,0:11:15.838
despite multiple removal attempts [br]over almost a year.

0:11:16.721,0:11:23.143
At some point in the future, [br]we will hopefully have HTTPS-Only mode

0:11:23.143,0:11:28.449
enabled by default in Tor Browser [br]to kill this entire attack vector for good

0:11:28.449,0:11:32.203
and make malicious exits less lucrative.

0:11:32.203,0:11:37.242
I encourage you to test [br]HTTPS-Only mode in Tor Browser

0:11:37.242,0:11:42.135
and notify website operators [br]that do not work in that mode.

0:11:42.135,0:11:45.586
If a website does not work [br]in HTTPS-Only mode,

0:11:45.586,0:11:50.078
you also know it is probably [br]not safe to use in the first place.

0:11:51.806,0:11:57.106
The second example actor, [br]tracked as KAX17,

0:11:57.106,0:12:02.728
is still somewhat of a mystery. And [br]that is not the best situation to be in.

0:12:02.728,0:12:07.032
They are remarkable for: [br]their focus on non-exit relays,

0:12:07.032,0:12:13.036
their network diversity, [br]with over 200 distinct /16 subnets,

0:12:13.036,0:12:19.432
their size – it is the first actor I know[br]of that peaked at over 100 Gbit/s

0:12:19.432,0:12:25.684
advertised non-exit bandwidth – and[br]they are active since a very long time.

0:12:27.422,0:12:32.059
Let's have a look at some KAX17 [br]related events in the past two years.

0:12:32.059,0:12:38.856
I first detected and reported them [br]to the Tor Project in September 2019.

0:12:38.856,0:12:44.084
In October 2019, [br]KAX17 relays got removed

0:12:44.084,0:12:47.459
by the Tor directory [br]authorities for the first time.

0:12:49.756,0:12:54.212
In December 2019,[br]I published the first blog post about them

0:12:54.212,0:12:57.783
At that point, they were already [br]rebuilding their infrastructure

0:12:57.783,0:13:00.576
by adding new relays.

0:13:01.827,0:13:07.791
In February 2020, I contacted an email [br]address that was used on some relays that

0:13:07.791,0:13:13.339
did not properly declare their relay group[br]using the "MyFamily" setting. At the time,

0:13:13.339,0:13:18.640
they said they would run bridges instead, [br]so they do not have to set MyFamily.

0:13:18.640,0:13:23.814
Side note: [br]MyFamily is not supported for bridges.

0:13:23.814,0:13:30.292
I was not aware that this email address[br]is linked to KAX17 until October 2021.

0:13:31.208,0:13:37.709
In the first half of 2020,[br]I regularly reported large quantities of

0:13:37.709,0:13:43.914
relays to the Tor Project, and they got[br]removed at high pace until June 2020,

0:13:43.914,0:13:48.444
when directory authorities changed their[br]practices and stopped removing them

0:13:48.444,0:13:53.600
because they didn't want to "scare away" [br]potential new relay operators.

0:13:54.859,0:13:58.524
In July 2020, an email address joined [br]a tor-relays mailing list discussion

0:13:58.524,0:14:07.178
I started about a proposal to limit [br]large-scale attacks on the network.

0:14:07.178,0:14:12.725
Now we know [br]that email address is linked to KAX17.

0:14:13.920,0:14:18.445
Since the Tor directory authorities [br]no longer removed the relay groups

0:14:18.445,0:14:24.090
showing up, I sent the information [br]of over 600 KAX17 relays

0:14:24.090,0:14:26.518
to the public tor-talk mailing list.

0:14:27.703,0:14:32.321
In October 2021, someone who asked for [br]anonymity reached out to me and provided a

0:14:32.321,0:14:39.287
new way to detect Tor relay groups that [br]do not run the official Tor software.

0:14:40.518,0:14:45.351
Using this methodology, [br]we were able to detect KAX17

0:14:45.351,0:14:47.722
using a second detection method.

0:14:47.722,0:14:52.224
This also apparently convinced [br]the Tor directory authorities,

0:14:52.224,0:14:57.095
and in November this year, [br]a major removal event took place.

0:14:58.530,0:15:03.889
Sadly, the time span during which[br]KAX17 was running relays without

0:15:03.889,0:15:11.480
limitations was rather long. [br]This motivated us to come up with a

0:15:11.480,0:15:16.598
design that avoids this kind of complete [br]dependency on Tor directory authorities

0:15:16.598,0:15:19.262
when it comes to safety issues.

0:15:20.032,0:15:22.810
And, as you might guess,

0:15:22.810,0:15:27.372
KAX17 is already attempting [br]to restore their foothold again.

0:15:30.009,0:15:33.404
Here are some KAX17 properties.

0:15:33.404,0:15:39.502
After the release of my second [br]KAX17 blog post in November 2021,

0:15:39.502,0:15:43.819
the media was quick with using [br]words like "nation-state" and

0:15:43.819,0:15:46.860
"Advanced Persistent Threat".

0:15:46.860,0:15:53.175
But I find it hard to believe such such [br]serious entities would be so sloppy.

0:15:53.175,0:15:58.061
Since they claim to work for an ISP [br]in every other email…

0:15:58.797,0:16:02.144
I looked into their AS distribution.

0:16:02.800,0:16:06.881
I guess they work for more than one ISP.

0:16:07.686,0:16:10.625
This chart shows used Autonomous System,

0:16:10.625,0:16:15.972
sorted by the unique IP addresses [br]used at that hoster. So, for example,

0:16:15.972,0:16:21.178
They used more than 400 IP [br]addresses at Microsoft to run relays.

0:16:21.178,0:16:27.009
These are not exact numbers,[br]since it only includes relays since 2019,

0:16:27.009,0:16:33.019
and there are likely more.[br]If we map their IP addresses

0:16:33.019,0:16:39.050
to countries, we get this. Do not take[br]this map too seriously, as the used GEOIP

0:16:39.050,0:16:44.819
database was severely outdated and such[br]databases are never completely accurate,

0:16:44.819,0:16:54.980
but it gives us a rough idea. To be clear,[br]I have no evidence that KAX17 is

0:16:54.980,0:17:00.670
performing any kind of attacks against Tor[br]users, but in our threat model it is

0:17:00.670,0:17:06.069
already a considerable risk if even a[br]benevolent operator is not declaring their

0:17:06.069,0:17:12.039
more than 800 relays as a family. Good[br]protections should protect against

0:17:12.039,0:17:17.809
benevolent and malicious Sybil attacks[br]equally. The strongest input factor for

0:17:17.809,0:17:23.240
the risk assessment of this actor is the[br]fact they do not run the official Tor

0:17:23.240,0:17:28.769
software on their relays. There are still[br]many open questions, and the analysis into

0:17:28.769,0:17:39.370
KAX17 is ongoing. If you have any input,[br]feel free to reach out to me. After

0:17:39.370,0:17:44.419
looking at some examples of malicious[br]actors, I want to shortly summarize some

0:17:44.419,0:17:51.519
of the issues in how the malicious relays[br]problem is currently approached. It is

0:17:51.519,0:17:56.690
pretty much like playing Whack-A-Mole. You[br]hit them and they come back. You hit them

0:17:56.690,0:18:02.620
again, and they come back again, over and[br]over and while you're at it, you're also

0:18:02.620,0:18:08.580
training them to come back stronger next[br]time. Malicious actors can run relays

0:18:08.580,0:18:14.669
until they get caught/detected or are[br]considered suspicious enough for removal

0:18:14.669,0:18:20.630
by a Tor directory authorities. If your[br]threat model does not match the Tor

0:18:20.630,0:18:25.179
directory's threat model, you are out of[br]luck or have to maintain your own

0:18:25.179,0:18:31.370
exclusion lists. Attempts to define a[br]former set of "do not do" requirements for

0:18:31.370,0:18:36.991
relays that Tor directory authorities[br]commit to enforce, have failed, even with

0:18:36.991,0:18:45.760
the involvement of a core Tor developer.[br]It is time for a paradigm change. The

0:18:45.760,0:18:50.799
current processes for detecting and[br]removing malicious Tor relays are failing

0:18:50.799,0:18:56.660
us and are not sustainable in the long[br]run. In recent years, malicious groups

0:18:56.660,0:19:05.660
have become larger, harder to detect,[br]harder to get removed and more persistent.

0:19:05.660,0:19:11.970
Here are some of our design goals. Instead[br]of continuing the single sided arms race

0:19:11.970,0:19:17.389
with malicious actors. We aim to empower[br]Tor users for self-defense without

0:19:17.389,0:19:22.260
requiring the detection of malicious Tor[br]relays and without, solely, depending on

0:19:22.260,0:19:28.389
Tor directly authorities for protecting us[br]from malicious relays. We aim to reduce

0:19:28.389,0:19:36.899
the risk of de-anonymization by using at[br]least a trusted guard or exit or both. We

0:19:36.899,0:19:41.440
also acknowledge it is increasingly[br]impossible to detect all malicious relays

0:19:41.440,0:19:46.990
using decoy traffic, therefore, we stop[br]depending on the detectability of

0:19:46.990,0:19:56.270
malicious relays to protect users. In[br]today's Tor network, we hope to not choose

0:19:56.270,0:20:01.519
a malicious guard when we pick one. In the[br]proposed design, we would pick a trusted

0:20:01.519,0:20:07.620
guard instead. In fact, this can be done[br]with today's Tor browser, if you set any

0:20:07.620,0:20:14.289
trusted relays as your bridge. Another[br]supported configuration would be to use

0:20:14.289,0:20:20.169
trusted guards and trusted exits. Such[br]designs are possible without requiring

0:20:20.169,0:20:25.370
code changes in Tor, but are cumbersome to[br]configure manually, since Tor only

0:20:25.370,0:20:33.310
supports relay fingerprints and does not[br]know about relay operator identifiers. But

0:20:33.310,0:20:39.460
what do we actually mean by trusted[br]relays? Trusted relays are operated by

0:20:39.460,0:20:45.380
trusted operators. These operators are[br]believed to run relays without malicious

0:20:45.380,0:20:51.559
intent. Trusted operators are specified by[br]the user. Users assign trust at the

0:20:51.559,0:20:57.450
operator, not the relay level, for[br]scalability reasons, and to avoid

0:20:57.450,0:21:05.990
configuration changes when an operator[br]changes their relays. Since users should

0:21:05.990,0:21:12.100
be able to specify trusted operators, we[br]need human-readable, authenticated and

0:21:12.100,0:21:19.029
globally unique operator identifiers. By[br]authenticated, we mean they should not be

0:21:19.029,0:21:26.700
spoofable arbitrarily like current relay[br]contact infos. For simplicity, we use DNS

0:21:26.700,0:21:34.140
domains as relay operator identifiers, and[br]we will probably restrict them to 40

0:21:34.140,0:21:47.000
characters in length. How do Authenticated[br]Relay Operator IDs, short AROI, work. From

0:21:47.000,0:21:52.490
an operator point of view, configuring an[br]AROI is easy. Step one: The operator

0:21:52.490,0:21:59.559
specifies the desired domain under her[br]control using Tor's ContactInfo option.

0:21:59.559,0:22:06.850
Step two: The operator publishes a simple[br]text file using the IANA well-known URI

0:22:06.850,0:22:13.100
containing all relay fingerprints. If no[br]web server is available or if the web

0:22:13.100,0:22:18.710
server is not considered safe enough,[br]DNSSEC-signed TXT records are also an

0:22:18.710,0:22:25.580
option for authentication. Using DNS is[br]great for scalability and availability due

0:22:25.580,0:22:31.299
to DNS caching, but since every relay[br]requires its own TXT record, it will take

0:22:31.299,0:22:37.110
longer than the URI type proof when[br]performing proof validation. Operators

0:22:37.110,0:22:42.370
that have no domain at all can use free[br]services like GitHub pages or similar to

0:22:42.370,0:22:49.870
serve the text file. For convenience, Eran[br]Sandler created this simple to use

0:22:49.870,0:22:55.100
ContactInfo generator, so relay operators[br]don't have to read the specification to

0:22:55.100,0:23:00.530
generate the required ContactInfo string[br]for their configuration. For the

0:23:00.530,0:23:06.290
Authenticated Relay Operator ID the "url"[br]and "proof" fields are the only relevant

0:23:06.290,0:23:13.720
fields. There are already over 1000 relays[br]that have implemented the Authenticated

0:23:13.720,0:23:21.690
Relay Operator ID. OrNetStats displays an[br]icon in case the operator implemented it

0:23:21.690,0:23:29.110
correctly. Out of the top 24 largest[br]families by bandwidth, all but eight

0:23:29.110,0:23:34.720
operators have implemented the[br]Authenticated Relay Operator ID already.

0:23:34.720,0:23:40.380
On the right-hand side, you can see a few[br]logos of organizations running relays with

0:23:40.380,0:23:46.639
a properly set up AROI. The most relevant[br]distinction between lines having that

0:23:46.639,0:23:51.790
checkmark icon and those that do not have[br]it is the fact that the string in lines

0:23:51.790,0:23:59.409
that do not include the icon can be[br]arbitrarily spoofed. This graph shows the

0:23:59.409,0:24:05.549
largest exit operators that implemented[br]the AROI. I want to stress one crucial

0:24:05.549,0:24:12.660
point about AROIs though, authenticated[br]must not be confused with trusted.

0:24:12.660,0:24:19.200
Malicious operators can also authenticate[br]their domain and they do. A given AROI can

0:24:19.200,0:24:25.529
be trusted or not. It is up to the user,[br]but using AROIs instead of ContactInfo for

0:24:25.529,0:24:30.669
assigning trust is crucial because[br]ContactInfo can not be trusted directly

0:24:30.669,0:24:37.840
without further checks. This graph shows[br]what fraction of the Tor network's exit

0:24:37.840,0:24:43.769
capacity implemented the Authenticated[br]Relay Operator ID over time. Currently, we

0:24:43.769,0:24:49.529
are at around 60 percent already, but[br]guard capacity is a lot lower, around 15

0:24:49.529,0:24:55.880
percent. The reason for that is that exits[br]are operated mostly by large operators and

0:24:55.880,0:25:00.909
organizations, while guards are[br]distributed across a lot more operators.

0:25:00.909,0:25:11.450
There are over 1800 guard families, but[br]only around 400 exit families. How does a

0:25:11.450,0:25:19.380
Tor client make use of AROIs, current Tor[br]versions do not know what AROIs are and

0:25:19.380,0:25:24.690
primarily take relay fingerprints as[br]configuration inputs. So, we need some

0:25:24.690,0:25:28.980
tooling to generate a list of relay[br]fingerprints starting from a list of

0:25:28.980,0:25:36.919
trusted AROIs. We have implemented a quick[br]and dirty proof of concept that puts

0:25:36.919,0:25:41.370
everything together and performs all the[br]steps shown on this slide, to demonstrate

0:25:41.370,0:25:47.100
the concept of using trusted AROIs to[br]configure Tor client to use trusted exit

0:25:47.100,0:25:53.639
relays. It is not meant to be used by end-[br]users, it merely is a preview for the

0:25:53.639,0:25:57.570
technical audience who would like to see[br]it in action to achieve a better

0:25:57.570,0:26:03.870
understanding of the design. The current[br]proof of concept performs all proof checks

0:26:03.870,0:26:09.799
itself without relying on third parties,[br]but since there are a lot of reasons for

0:26:09.799,0:26:15.080
doing proof-checks centrally instead, for[br]example, by directory authorities. I

0:26:15.080,0:26:21.080
recently submitted a partial proposal for[br]it to the Tor development mailing list to

0:26:21.080,0:26:25.080
see whether they would consider it before[br]proceeding with a more serious

0:26:25.080,0:26:30.950
implementation than the current proof of[br]concept. I find it important to always try

0:26:30.950,0:26:35.820
achieving a common goal together with[br]upstream first before creating solutions

0:26:35.820,0:26:40.769
that are maintained outside of upstream[br]because it will lead to better maintained

0:26:40.769,0:26:46.179
improvements and likely a more user-[br]friendly experience if they are integrated

0:26:46.179,0:26:52.909
in upstream. Here is a link to the[br]mentioned tor-dev email, for those who

0:26:52.909,0:27:01.789
would like to follow along. To summarize,[br]after reviewing some real world examples

0:27:01.789,0:27:08.200
of malicious actors on the Tor network, we[br]concluded that current approaches to limit

0:27:08.200,0:27:16.269
risks by bad relays on Tor users might not[br]live up to Tor users expectations, are not

0:27:16.269,0:27:22.490
sustainable in the long run and need an[br]upgrade to avoid depending on the

0:27:22.490,0:27:28.610
detectability of malicious relays, which[br]is becoming increasingly hard. We

0:27:28.610,0:27:34.909
presented a design to extend current anti[br]bad relay approaches that does not rely on

0:27:34.909,0:27:41.340
the detection of malicious relays using[br]trusted Authenticated Relay Operator IDs.

0:27:41.340,0:27:47.080
We have shown that most exit capacity has[br]implemented AROIs already, while guard

0:27:47.080,0:27:53.289
capacity is currently significantly lower,[br]showing a lack of insights on who operates

0:27:53.289,0:28:00.100
Tor's guard capacity. When publicly[br]speaking about modifying Tor's path

0:28:00.100,0:28:06.590
selection in front of a wide audience, I[br]also consider it to be my responsibility

0:28:06.590,0:28:12.759
to explicitly state that you should not[br]change your Tor configuration options that

0:28:12.759,0:28:18.380
influenced path selection behavior without[br]a clear need, according to your threat

0:28:18.380,0:28:26.230
model to avoid potentially standing out.[br]Using trusted AROIs certainly comes with

0:28:26.230,0:28:31.990
some tradeoffs of its own, like for[br]example, network load balancing, to name

0:28:31.990,0:28:38.570
only one. Thanks to many large, trusted[br]exit operators, it should be feasible in

0:28:38.570,0:28:43.090
the near future to use trusted exits[br]without standing out in a trivially

0:28:43.090,0:28:49.259
detectable way because it is harder in the[br]sense of takes longer to statistically

0:28:49.259,0:28:55.110
detect a Tor client changed its possible[br]pool of exits, if it only excluded a

0:28:55.110,0:29:02.519
smaller fraction of exits. Detecting Tor[br]clients using only a subset of all guards

0:29:02.519,0:29:08.539
takes a lot longer than detecting custom[br]exit sets because guards are not changed

0:29:08.539,0:29:16.120
over a longer period of time when compared[br]with exits. And finally, Tor clients that

0:29:16.120,0:29:22.860
make use of trusted AROIs will need a way[br]to find trusted AROIs, ideally, they could

0:29:22.860,0:29:29.789
learn about them dynamically in a safe[br]way. There is an early work in progress

0:29:29.789,0:29:40.399
draft specification linked on this slide.[br]I want to dedicate this talk to Karsten

0:29:40.399,0:29:47.309
Loesing who passed away last year. He was[br]the kindest person I got to interact with

0:29:47.309,0:29:54.059
in the Tor community. Karsten was the Tor[br]metrics team lead and without his work, my

0:29:54.059,0:29:59.830
projects, OrNetStats and OrNetRadar would[br]not exist. Every time you use

0:29:59.830,0:30:07.389
metrics.torproject.org, for example, the[br]so-called "Relay Search", you are using

0:30:07.389,0:30:14.730
his legacy. Thank you for listening, and[br]I'm really looking forward to your

0:30:14.730,0:30:19.629
questions. I'm not sure I'll be able to[br]respond to questions after the talk in

0:30:19.629,0:30:23.980
real time, but it would be nice to have[br]them read out. So they are part of the

0:30:23.980,0:30:28.659
recording and I'll make an effort to[br]publish answers to all of them via

0:30:28.659,0:30:35.679
Mastodon, should I not be able to respond[br]in real time. I'm also happy to take tips

0:30:35.679,0:30:40.720
about unusual things you observed on the[br]Tor network. Do not underestimate your

0:30:40.720,0:30:48.200
power as Tor user to contribute to a safer[br]Tor network by reporting unusual things.

0:30:48.200,0:30:55.050
Most major hits against bad relay actors[br]were the result of Tor user reports.

0:30:55.050,0:31:18.540
<i>quietness</i>

0:31:18.540,0:31:27.809
Herald: OK. Thank you very much for this[br]very informative talk and yes so we will

0:31:27.809,0:31:41.059
switch over to the Q&amp;A now. Yeah, thanks[br]again. Very fascinating. So we have

0:31:41.059,0:31:50.609
collected several questions from our IRC[br]chat, so I'm just going to start. If

0:31:50.609,0:31:57.270
bridges don't need the MyFamily setting[br]isn't this a wide open gap for end-to-end

0:31:57.270,0:32:03.840
correlation attacks, for example if a[br]malicious actor can somehow make the relay

0:32:03.840,0:32:10.179
popular as bridge?[br]Nusenu: Yes, bridges are a concern in the

0:32:10.179,0:32:15.419
context of MyFamily, for that reason, it[br]is not recommended to run bridges and

0:32:15.419,0:32:20.200
exits at the same time in current versions[br]of Tor, but future versions of Tor will

0:32:20.200,0:32:26.200
get a new and more relay operator friendly[br]MyFamily setting. That new MyFamily design

0:32:26.200,0:32:33.539
will also support bridges. This will[br]likely be in Tor 0.4.8.x at some point in

0:32:33.539,0:32:45.110
2022.[br]Herald: OK, thanks. Despite what kind of

0:32:45.110,0:32:55.120
attack, are there statistics who or from[br]which country these attacks are coming

0:32:55.120,0:33:02.799
most? Background here is there are rumors[br]about NSA driven and exit notes.

0:33:02.799,0:33:08.389
Nusenu: I don't know about any general[br]statistics, but I usually include used

0:33:08.389,0:33:13.610
autonomous systems by certain groups when[br]blogging about them. There are some

0:33:13.610,0:33:17.899
autonomous systems that are notorious for[br]being used by malicious groups, but

0:33:17.899,0:33:23.200
malicious groups also try to blend in with[br]the rest by using large ISPs like Hetzner

0:33:23.200,0:33:30.750
and OVH.[br]Herald: Thanks. Is using a bridge that I

0:33:30.750,0:33:35.009
host also safer than using a random guard[br]node?

0:33:35.009,0:33:41.790
Nusenu: This is a tricky question, since[br]it also depends on whether it is a private

0:33:41.790,0:33:47.380
bridge, a bridge that is not distributed[br]to other uses by a bridgeDB. I would say

0:33:47.380,0:33:53.470
it is better to not run the bridges you[br]use yourself.

0:33:53.470,0:34:02.759
Herald: OK. What is worse? KAX17 or a well[br]known trusted operators running 20 percent

0:34:02.759,0:34:06.850
of Tor's exits?[br]Nusenu: Currently, I would say KAX17.

0:34:06.850,0:34:17.460
Herald: OK. I think that's the last one[br]for now: Isn't the anonymity, not

0:34:17.460,0:34:22.210
decreased or changed while using trusted[br]relay list?

0:34:22.210,0:34:27.000
Nusenu: Yes, this is a trade-off that[br]users will need to make. This heavily

0:34:27.000,0:34:36.860
depends on the threat model.[br]Herald: OK. So I think we have gathered

0:34:36.860,0:34:42.510
all the questions and they were all[br]answered. So thank you again for. Yes,

0:34:42.510,0:34:46.225
thank you again.

0:34:46.225,0:34:59.180
<i>rc3 postroll music</i>

0:34:59.180,0:35:03.000
Subtitles created by c3subtitles.de[br]in the year 2022. Join, and help us!#