Dr Gareth Owen: Tor: Hidden Services and Deanonymisation

silent 31C3 preroll

Dr. Gareth Owen: Hello. Can you hear me?
Yes. Okay. So my name is Gareth Owen.

I’m from the University of Portsmouth.
I’m an academic

and I’m going to talk to you about
an experiment that we did

on the Tor hidden services,
trying to categorize them,

estimate how many they were etc. etc.

Well, as we go through the talk
I’m going to explain

how Tor hidden services work internally,
and how the data was collected.

So what sort of conclusions you can draw
from the data based on the way that we’ve

collected it. Just so [that] I get
an idea: how many of you use Tor

on a regular basis, could you
put your hand up for me?

So quite a big number. Keep your hand
up if… or put your hand up if you’re

a relay operator.

Wow, that’s quite a significant number,
isn’t it? And then, put your hand up

and/or keep it up if you
run a hidden service.

Okay, so, a fewer number, but still
some people run hidden services.

Okay, so, some of you may be very familiar
with the way Tor works, sort of,

in a low level. But I am gonna go through
it for those which aren’t, so they understand

just how they work. And as we go along,
because I’m explaining how

the hidden services work, I’m going
to tag on information on how

the Tor hidden services themselves can be
deanonymised and also how the users

of those hidden services can be
deanonymised, if you put

some strict criteria on what it is you
want to do with respect to them.

So the things that I’m going to go over:
I wanna go over how Tor works,

and then specifically how hidden services
work. I’m gonna talk about something

called the “Tor Distributed Hash Table”
for hidden services. If you’ve heard

that term and don’t know what
it means, don’t worry, I’ll explain

what a distributed hash table is and
how it works. It’s not as complicated

as it sounds. And then I wanna go over
Darknet data, so, data that we collected

from Tor hidden services. And as I say,
as we go along I will sort of explain

how you do deanonymisation of both the
services themselves and of the visitors

to the service. And just
how complicated it is.

So you may have seen this slide which
I think was from GCHQ, released last year

as part of the Snowden leaks where they
said: “You can deanonymise some users

some of the time but they’ve had
no success in deanonymising someone

in response to a specific request.”
So, given all of you e.g., I may be able

to deanonymise a small fraction of you
but I can’t choose precisely one person

I want to deanonymise. That’s what
I’m gonna be explaining in relation

to the deanonymisation attacks, how
you can deanonymise a section but

you can’t necessarily choose which section
of the users that you will be deanonymising.

Tor drives with just a couple
of different problems. On one part

it allows you to bypass censorship. So if
you’re in a country like China, which

blocks some types of traffic you can use
Tor to bypass their censorship blocks.

It tries to give you privacy, so, at some
level in the network someone can’t see

what you’re doing. And at another point
in the network people who don’t know

who you are but may necessarily
be able to see what you’re doing.

Now the traditional case
for this is to look at VPNs.

With a VPN you have
sort of a single provider.

You have lots of users connecting
to the VPN. The VPN has sort of

a mixing effect from an outside or
a server’s point of view. And then

out of the VPN you see requests
to Twitter, Wikipedia etc. etc.

And if that traffic doesn’t encrypt it then
the VPN can also read the contents

of the traffic. Now of course there is
a fundamental weakness with this.

If you trust the VPN provider the VPN
provider knows both who you are

and what you’re doing and can
link those two together with absolute

certainty. So you don’t… whilst you do
get some of these properties, assuming

you’ve got a trustworthy VPN provider
you don’t get them in the face of

an untrustworthy VPN provider.
And of course: how do you trust the VPN

provider? What sort of measure do
you use? That’s sort of an open question.

So Tor tries to solve this problem
by distributing the trust. Tor is

an open source project, so you can go
on to their Git repository, you can

download the source code, and change it,
improve it, submit patches etc.

As you heard earlier, during Jacob and
Roger’s talk they’re currently partly

sponsored by the US Government which seems
a bit paradoxical, but they explained

in that talk many of the… that
doesn’t affect like judgment.

And indeed, they do have some funding from
other sources, and they design that system

– which I’ll talk about a little bit
later – in a way where they don’t have

to trust each other. So there’s sort of
some redundancy, and they’re trying

to minimize these sort of trust issues
related to this. Now, Tor is

a partially de-centralized network, which
means that it has some centralized

components which are under the control of
the Tor Project and some de-centralized

components which are normally the Tor
relays. If you run a relay you’re

one of those de-centralized components.
There is, however, no single authority

on the Tor network.
So no single server which is responsible,

which you’re required to trust.
So the trust is somewhat distributed,

but not entirely. When you establish
a circuit through Tor you, the user,

download a list of all of the relays
inside the Tor network.

And you get to pick – and I’ll tell you
how you do that – which relays

you’re going to use to route your traffic
through. So here is a typical example:

You’re here on the left hand side as the
user. You download a list of the relays

inside the Tor network and you select from
that list three nodes, a guard node

which is your entry into the Tor network,
a relay node which is a middle node.

Essentially, it’s going to route your
traffic to a third hop. And then

the third hop is the exit node where
your traffic essentially exits out

on the internet. Now, looking at the
circuit. So this is a circuit through

the Tor network through which you’re
going to route your traffic. There are

three layers of encryption at the
beginning, so between you

and the guard node. Your traffic
is encrypted three times.

In the first instance encrypted to the
guard, and the it’s encrypted again,

through the relay, and then encrypted
again to the exit, and as the traffic moves

through the Tor network each of those
layers of encryption are unpeeled

from the data. The Guard here in this case
knows who you are, and the exit relay

knows what you’re doing but neither know
both. And the middle relay doesn’t really

know a lot, except for which relay is
her guard and which relay is her exit.

Who runs an exit relay? So if you run
an exit relay all of the traffic which

users are sending out on the internet they
appear to come from your IP address.

So running an exit relay is potentially
risky because someone may do something

through your relay which attracts attention.
And then, when law enforcement

traced that back to an IP address it’s
going to come back to your address.

So some relay operators have had trouble
with this, with law enforcement coming

to them, and saying: “Hey we got this
traffic coming through your IP address

and you have to go and explain it.”
So if you want to run an exit relay

it’s a little bit risky, but we’re thankful
for those people that do run exit relays

because ultimately if people didn’t run
an exit relay you wouldn’t be able

to get out of the Tor network, and it
wouldn’t be terribly useful from this

point of view. So, yes.
applause

So every Tor relay, when you set up
a Tor relay you publish something called

a descriptor which describes your Tor
relay and how to use it to a set

of servers called the authorities. And the
trust in the Tor network is essentially

split across these authorities. They’re run
by the core Tor Project members.

And they maintain a list of all of the
relays in the network. And they observe

them over a period of time. If the relays
exhibit certain properties they give

the relays flags. If e.g. a relay allows
traffic to exit from the Tor network

it will get the ‘Exit’ flag. If they’d been
switched on for a certain period of time,

or for a certain amount of traffic they’ll
be allowed to become the guard relay

which is the first node in your circuit.
So when you build your circuit you

download a list of these descriptors from
one of the Directory Authorities. You look

at the flags which have been assigned to
each of the relays, and then you pick

your route based on that. So you’ll pick
the guard node from a set of relays

which have the ‘Guard’ flag, your exits
from the set of relays which have

the ‘Exit’ flag etc. etc. Now, as of
a quick count this morning there are

about 1500 guard relays, around 1000 exit
relays, and six relays flagged as ‘bad’ exits.

What does a ‘bad exit’ mean?
waits for audience to respond

That’s not good! That’s exactly
what it means! Yes! laughs

applause

So relays which have been flagged as ‘bad
exits’ your client will never chose to exit

traffic through. And examples of things
which may get a relay flagged as an

[bad] exit relay – if they’re fiddling with
the traffic which is coming out of

the Tor relay. Or doing things like
man-in-the-middle attacks against

SSL traffic. We’ve seen various things,
there have been relays man-in-the-middling

SSL traffic, there have very, very recently
been an exit relay which was patching

binaries that you downloaded from the
internet, inserting malware into the binaries.

So you can do these things but the Tor
Project tries to scan for them. And if

these things are detected then they’ll be
flagged as ‘Bad Exits’. It’s true to say

that the scanning mechanism is not 100%
fool-proof by any stretch of the imagination.

It tries to pick up common types
of attacks, so as a result

it won’t pick up unknown attacks or
attacks which haven’t been seen or

have not been known about beforehand.

So looking at this, how do you deanonymise
the traffic travelling through the Tor

networks? Given some traffic coming out
of the exit relay, how do you know

which user that corresponds to? What is
their IP address? You can’t actually

modify the traffic because if any of the
relays tried to modify the traffic

which they’re sending through the network
Tor will tear down the circuit through the relay.

So there’s these integrity checks, each
of the hops. And if you try to sort of

– because you can’t decrypt the packet
you can’t modify it in any meaningful way,

and because there’s an integrity check
at the next hop that means that you can’t

modify the packet because otherwise it’s
detected. So you can’t do this sort of

marker, and try and follow the marker
through the network. So instead

what you can do if you control… so let me
give you two cases. In the worst case

if the attacker controls all three of your
relays that you pick, which is an unlikely

scenario that needs to control quite
a big proportion of the network. Then

it should be quite obvious that they can
work out who you are and also

see what you’re doing because in that
case they can tag the traffic, and

they can just discard these integrity
checks at each of the following hops.

Now in a different case, if you control
the Guard relay and the exit relay

but not the middle relay the Guard relay
can’t tamper with the traffic because

this middle relay will close down the
circuit as soon as it happens.

The exit relay can’t send stuff back down
the circuit to try and identify the user,

either. Because again, the circuit will be
closed down. So what can you do?

Well, you can count the number of packets
going through the Guard node. And you can

measure the timing differences between
packets, and try and spot that pattern

at the Exit relays. You’re looking at counts of
packets and the timing between those

packets which are being sent, and
essentially trying to correlate them all.

So if your user happens to pick you as
your Guard node, and then happens to pick

your exit relay, then you can deanonymise
them with very high probability using

this technique. You’re just correlating
the timings of packets and counting

the number of packets going through.
And the attacks demonstrated in literature

are very reliable for this. We heard
earlier from the Tor talk about the “relay

early” tag which was the attack discovered
by the cert researches in the US.

That attack didn’t rely on timing attacks.
Instead, what they were able to do was

send a special type of cell containing
the data back down the circuit,

essentially marking this data, and saying:
“This is the data we’re seeing

at the Exit relay, or at the hidden
service", and encode into the messages

travelling back down the circuit, what the
data was. And then you could pick

those up at the Guard relay and say, okay,
whether it’s this person that’s doing that.

In fact, although this technique works,
and yeah it was a very nice attack,

the traffic correlation attacks are
actually just as powerful.

So although this bug has been fixed traffic
correlation attacks still work and are

still fairly, fairly reliable. So the problem
still does exist. This is very much

an open question. How do we solve this
problem? We don’t know, currently,

how to solve this problem of trying
to tackle the traffic correlation.

There are a couple of solutions.
But they’re not particularly…

they’re not particularly reliable. Let me
just go through these, and I’ll skip back

on the few things I’ve missed. The first
thing is, high-latency networks, so

networks where packets are delayed
in their transit through the network.

That throws away a lot of the timing
information. So they promise

to potentially solve this problem.
But of course, if you want to visit

Google’s home page, and you have to wait
five minutes for it, you’re simply

just not going to use Tor. The whole point
is trying to make this technology usable.

And if you got something which is very,
very slow then it doesn’t make it

attractive to use. But of course,
this case does work slightly better

for e-mail. If you think about it with
e-mail, you don’t mind if you’re e-mail

– well, you may not mind, you may mind –
you don’t mind if your e-mail is delayed

by some period of time. Which makes this
somewhat difficult. And as Roger said

earlier, you can also introduce padding
into the circuit, so these are dummy cells.

But, but… with a big caveat: some of the
research suggests that actually you’d

need to introduce quite a lot of padding
to defeat these attacks, and that would

overload the Tor network in its current
state. So, again, not a particular

practical solution.

How does Tor try to solve this problem?
Well, Tor makes it very difficult

to become a users Guard relay. If you
can’t become a users Guard relay

then you don’t know who the user is, quite
simply. And so by making it very hard

to become the Guard relay therefore you
can’t do this traffic correlation attack.

So at the moment the Tor client chooses
one Guard relay and keeps it for a period

of time. So if I want to sort of target
just one of you I would need to control

the Guard relay that you were using at
that particular point in time. And in fact

I’d also need to know what that Guard
relay is. So by making it very unlikely

that you would select a particular malicious
Guard relay, where the number of malicious

Guard relays is very small, that’s how Tor
tries to solve this problem. And

at the moment your Guard relay is your
barrier of security. If the attacker can’t

control the Guard relay then they won’t
know who you are. That doesn’t mean

they can’t try other sort of side channel
attacks by messing with the traffic

at the Exit relay etc. You know that you
may sort of e.g. download dodgy documents

and open one on your computer, and those
sort of things. Now the alternative

of course to having a Guard relay
and keeping it for a very long time

will be to have a Guard relay and
to change it on a regular basis.

Because you might think, well, just choosing
one Guard relay and sticking with it

is probably a bad idea. But actually,
that’s not the case. If you pick

the Guard relay, and assuming that the
chance of picking a Guard relay that is

malicious is very low, then, when you
first use your Guard relay, if you got

a good choice, then your traffic is safe.
If you haven’t got a good choice then

your traffic isn’t safe. Whereas if your
Tor client chooses a Guard relay

every few minutes, or every hour, or
something on those lines at some point

you’re gonna pick a malicious Guard relay.
So they’re gonna have some of your traffic

but not all of it. And so currently the
trade-off is that we make it very difficult

for an attacker to control a Guard relay
and the user picks a Guard relay and

keeps it for a long period of time. And
so it’s very difficult for the attackers

to pick that Guard relay when they control
a very small proportion of the network.

So this, currently, provides those
properties I described earlier, the privacy

and the anonymity when you’re browsing the
web, when you’re accessing websites etc.

But still you know who the website is. So
although you’re anonymous and the website

doesn’t know who you are you know who the
website is. And there may be some cases

where e.g. the website would also wish to
remain anonymous. You want the person

accessing the website and the website
itself to be anonymous to each other.

And you could think about people e.g.
being in countries where running

a political blog e.g. might be a dangerous
activity. If you run that on a regular

webserver you’re easily identified whereas,
if you got some way where you as

the webserver can be anonymous then
that allows you to do that activity without

being targeted by your government. So
this is what hidden services try to solve.

Now when you first think about a problem
you kind of think: “Hang on a second,

the user doesn’t know who the website
is and the website doesn’t know

who the user is. So how on earth do they
talk to each other?” Well, that’s essentially

what the Tor hidden service protocol tries
to sort of set up. How do you identify and

connect to each other. So at the moment
this is what happens: We’ve got Bob

on the [right] hand side who is the hidden
service. And we got Alice on the left hand

side here who is the user who wishes to
visit the hidden service. Now when Bob

sets up his hidden service he picks three
nodes in the Tor network as introduction

points and builds several hop circuits to
them. So the introduction points don’t know

who Bob is. Bob has circuits to them. And
Bob says to each of these introduction points

“Will you relay traffic to me if someone
connects to you asking for me?”

And then those introduction points
do that. So then, once Bob has picked

his introduction points he publishes
a descriptor describing the list of his

introduction points for someone who wishes
to come onto his websites. And then Alice

on the left hand side wishing to visit Bob
will pick a rendezvous point in the network

and build a circuit to it. So this “RP”
here is the rendezvous point.

And she will relay a message via one of
the introduction points saying to Bob:

“Meet me at the rendezvous point”.
And then Bob will build a 3-hop-circuit

to the rendezvous point. So now at this
stage we got Alice with a multi-hop circuit

to the rendezvous point, and Bob with
a multi-hop circuit to the rendezvous point.

Alice and Bob haven’t connected to one
another directly. The rendezvous point

doesn’t know who Bob is, the rendezvous
point doesn’t know who Alice is.

All they’re doing is forwarding the
traffic. And they can’t inspect the traffic,

either, because the traffic itself
is encrypted.

So that’s currently how you solve this
problem with trying to communicate

with someone who you don’t know
who they are and vice versa.

drinks from the bottle

The principle thing I’m going to talk
about today is this database.

So I said, Bob, when he picks his
introduction points he builds this thing

called a descriptor, describing who his
introduction points are, and he publishes

them to a database. This database itself
is distributed throughout the Tor network.

It’s not a single server. So both, Bob and
Alice need to be able to publish information

to this database, and also retrieve
information from this database. And Tor

currently uses something called
a distributed hash table, which I’m gonna

give an example of what this means and
how it works. And then I’ll talk to you

specifically how the Tor Distributed Hash
Table works itself. So let’s say e.g.

you've got a set of servers. So here we've
got 26 servers and you’d like to store

your files across these different servers
without having a single server responsible

for deciding, “okay, that file is stored
on that server, and this file is stored

on that server” etc. etc. Now here is my
list of files. You could take a very naive

approach. And you could say: “Okay, I’ve
got 26 servers, I got all of these file names

and start with the letter of the alphabet.”
And I could say: “All of the files that begin

with A are gonna go under server A; or
the files that begin with B are gonna go

on server B etc.” And then when you want
to retrieve a file you say: “Okay, what

does my file name begin with?” And then
you know which server it’s stored on.

Now of course you could have a lot of
servers – sorry – a lot of files

which begin with a Z, an X or a Y etc. in
which case you’re gonna overload

that server. You’re gonna have more files
stored on one server than on another server

in your set. And if you have a lot of big
files, say e.g. beginning with B then

rather than distributing your files across
all the servers you’re gonna just be

overloading one or two of them. So to
solve this problem what we tend to do is:

we take the file name, and we run it
through a cryptographic hash function.

A hash function produces output which
looks like random, very small changes

in the input so a cryptographic hash
function produces a very large change

in the output. And this change looks
random. So if I take all of my file names

here, and assuming I have a lot more,
I take a hash of them, and then I use

that hash to determine which server to
store the file on. Then, with high probability

my files will be distributed evenly across
all of the servers. And then when I want

to go and retrieve one of the files I take
my file name, I run it through the

cryptographic hash function, that gives me
the hash, and then I use that hash

to identify which server that particular
file is stored on. And then I go and

retrieve it. So that’s the sort of a loose
idea of how a distributed hash table works.

There are a couple of problems with this.
What if you got a changing size, what

if the number of servers you got changes
in size as it does in the Tor network.

It’s a very brief overview of the theory.
So how does it apply for the Tor network?

Well, the Tor network has a set of relays
and it has a set of hidden services.

Now we take all of the relays, and they
have a hash identity which identifies them.

And we map them onto a circle using that
hash value as an identifier. So you can

imagine the hash value ranging from Zero
to a very large number. We got a Zero point

at the very top there. And that runs all
the way round to the very large number.

So given the identity hash for a relay we
can map that to a particular point on

the server. And then all we have to do
is also do this for hidden services.

So there’s a hidden service address,
something.onion, so this is

one of the hidden websites that you might
visit. You take the – I’m not gonna describe

in too much detail how this is done but –
the value is done in such a way such that

it’s evenly distributed about the circle.
So your hidden service will have

a particular point on the circle. And the
relays will also be mapped onto this circle.

So there’s the relays. And the hidden
service. And in the case of Tor

the hidden service actually maps to two
positions on the circle, and it publishes

its descriptor to the three relays to the
right at one position, and the three relays

to the right at another position. So there
are actually in total six places where

this descriptor is published on the
circle. And then if I want to go and

fetch and connect to a hidden service
I go on to go and pull this hidden descriptor

down to identify what its introduction
points are. I take the hidden service

address, I find out where it is on the
circle, I map all of the relays onto

the circle, and then I identify which
relays on the circle are responsible

for that particular hidden service. And
I just connect, then I say: “Do you have

a copy of the descriptor for that
particular hidden service?”

And if so then we’ve got our list of
introduction points. And we can go

to the next steps to connect to our hidden
service. So I’m gonna explain how we

sort of set up our experiments. What we
thought, or what we were interested to do,

was collect publications of hidden
services. So for everytime a hidden service

gets set up it publishes to this distributed
hash table. What we wanted to do was

collect those publications so that we
get a complete list of all of the hidden

services. And what we also wanted to do
is to find out how many times a particular

hidden service is requested.

Just one more point that
will become important later.

The position which the hidden service
appears on the circle changes

every 24 hours. So there’s not
a fixed position every single day.

If we run 40 nodes over a long period of
time we will occupy positions within

that distributed hash table. And we will be
able to collect publications and requests

for hidden services that are located at
that position inside the distributed

hash table. So in that case we ran 40 Tor
nodes, we had a student at university

who said: “Hey, I run a hosting company,
I got loads of server capacity”, and

we told him what we were doing, and he
said: “Well, you really helped us out,

these last couple of years…”
and just gave us loads of server capacity

to allow us to do this. So we spun up 40
Tor nodes. Each Tor node was required

to advertise a certain amount of bandwidth
to become a part of that distributed

hash table. It’s actually a very small
amount, so this didn’t matter too much.

And then, after – this has changed
recently in the last few days,

it used to be 25 hours, it’s just been
increased as a result of one of the

attacks last week. But here… certainly
during our study it was 25 hours. You then

appear at a particular point inside that
distributed hash table. And you’re then

in a position to record publications of
hidden services and requests for hidden

services. So not only can you get a full
list of the onion addresses you can also

find out how many times each of the
onion addresses are requested.

And so this is what we recorded. And then,
once we had a full list of… or once

we had run for a long period of time to
collect a long list of .onion addresses

we then built a custom crawler that would
visit each of the Tor hidden services

in turn, and pull down the HTML contents,
the text content from the web page,

so that we could go ahead and classify
the content. Now it’s really important

to know here, and it will become obvious
why a little bit later, we only pulled down

HTML content. We didn’t pull out images.
And there’s a very, very important reason

for that which will become clear shortly.

We had a lot of questions when we
first started this. Noone really knew

how many hidden services there were. It had
been suggested to us there was a very high

turn-over of hidden services. We wanted to
confirm that whether that was true or not.

And we also wanted to do this so,
what are the hidden services,

how popular are they, etc. etc. etc. So
our estimate for how many hidden services

there are, over the period which we
ran our study, this is a graph plotting

our estimate for each of the individual
days as to how many hidden services

there were on that particular day. Now the
data is naturally noisy because we’re only

a very small proportion of that circle.
So we’re only observing a very small

proportion of the total publications and
requests every single day, for each of

those hidden services. And if you
take a long term average for this

there’s about 45.000 hidden services that
we think were present, on average,

each day, during our entire study. Which
is a large number of hidden services.

But over the entire length we
collected about 80.000, in total.

Some came and went etc.
So the next question after how many

hidden services there are is how long
the hidden service exists for.

Does it exist for a very long period
of time, does it exist for a very short

period of time etc. etc.
So what we did was, for every single

.onion address we plotted how many times
we saw a publication for that particular

hidden service during the six months.
How many times did we see it.

If we saw it a lot of times that suggested
in general the hidden service existed

for a very long period of time. If we saw
a very short number of publications

for each hidden service then that
suggests that they were only present

for a very short period of time. This is
our graph. By far the most number

of hidden services we only saw once during
the entire study. And we never saw them

again. We suggest that there’s a very high
turnover of the hidden services, they

don’t tend to exist on average i.e. for
a very long period of time.

And then you can see the sort of
a tail here. If we plot just those

hidden services which existed for a long
time, so e.g. we could take hidden services

which have a high number of hit requests
and say: “Okay, those that have a high number

of hits probably existed for a long time.”
That’s not absolutely certain, but probably.

Then you see this sort of -normal- plot
about 4..5, so we saw on average

most hidden services four or five times
during the entire six months if they were

popular and we’re using that as a proxy
measure for whether they existed

for the entire time. Now, this stage was
over 160 days, so almost six months.

What we also wanted to do was trying
to confirm this over a longer period.

So last year, in 2013, about February time
some researchers of the University

of Luxemburg also ran a similar study
but it ran over a very short period of time

over the day. But they did it in such
a way it could collect descriptors

across much of the circle during a single
day. That was because of a bug in the way

Tor did some of the things which has
now been fixed so we can’t repeat that

as a particular way. So we got a list of
.onion addresses from February 2013

from these researchers at the University
of Luxemburg. And then we got our list

of .onion addresses from this six months
which was March to September of this year.

And we wanted to say, okay, we’re given
these two sets of .onion addresses.

Which .onion addresses existed in his set
but not ours and vice versa, and which

.onion addresses existed in both sets?

So as you can see a very small minority
of hidden service addresses existed

in both sets. This is over an 18 month
period between these two collection points.

A very small number of services existed
in both his data set and in

our data set. Which again suggested
there’s a very high turnover of hidden

services that don’t tend to exist
for a very long period of time.

So the question is why is that?
Which we’ll come on to a little bit later.

It’s a very valid question, can’t answer
it 100%, we have some inclines as to

why that may be the case. So in terms
of popularity which hidden services

did we see, or which .onion addresses
did we see requested the most?

Which got the most number of hits? Or the
most number of directory requests.

So botnet Command & Control servers
– if you’re not familiar with what

a botnet is, the idea is to infect lots of
people with a piece of malware.

And this malware phones home to
a Command & Control server where

the botnet master can give instructions
to each of the bots on to do things.

So it might be e.g. to collect passwords,
key strokes, banking details.

Or it might be to do things like
Distributed Denial of Service attacks,

or to send spam, those sorts of things.
And a couple of years ago someone gave

a talk and said: “Well, the problem with
running a botnet is your C&C servers

are vulnerable.” Once a C&C server is taken
down you no longer have control over

your botnet. So it’s been a sort of arms
race against anti-virus companies and

against malware authors to try and come up
with techniques to run C&C servers in a way

which they can’t be taken down. And
a couple of years ago someone gave a talk

at a conference that said: “You know what?
It would be a really good idea if botnet

C&C servers were run as Tor hidden
services because then no one knows

where they are, and in theory they can’t
be taken down.” So in the fact we have this

there are loads and loads and loads of
these addresses associated with several

different botnets, ‘Sefnit’ and ‘Skynet’.
Now Skynet is the one I wanted to talk

to you about because the guy that runs
Skynet had a twitter account, and he also

did a Reddit AMA. If you not heard
of a Reddit AMA before, that’s a Reddit

ask-me-anything. You can go on the website
and ask the guy anything. So this guy

wasn’t hiding in the shadows. He’d say:
“Hey, I’m running this massive botnet,

here’s my Twitter account which I update
regularly, here is my Reddit AMA where

you can ask me questions!” etc.

He was arrested last year, which is not,
perhaps, a huge surprise.

laughter and applause

But… so he was arrested,
his C&C servers disappeared

but there were still infected hosts trying
to connect with the C&C servers and

request access to the C&C server.

This is why we’re saying: “A large number
of hits.” So all of these requests are

failed requests, i.e. we didn’t have
a descriptor for them because

the hidden service had gone away but
there were still clients requesting each

of the hidden services.

And the next thing we wanted to do was
to try and categorize sites. So, as I said

earlier, we crawled all of the hidden
services that we could, and we classified

them into different categories based
on what the type of content was

on the hidden service side. The first
graph I have is the number of sites

in each of the categories. So you can see
down the bottom here we got lots of

different categories. We got drugs, market
places, etc. on the bottom. And the graph

shows the percentage of the hidden
services that we crawled that fit in

to each of these categories. So e.g. looking
at this, drugs, the most number of sites

that we crawled were made up of
drugs-focused websites, followed by

market places etc. There’s a couple of
questions you might have here,

so which ones are gonna stick out, what
does ‘porn’ mean, well, you know

what ‘porn’ means. There are some very
notorious porn sites on the Tor Darknet.

There was one in particular which was
focused on revenge porn. It turns out

that youngsters wish to take pictures
of themselves, and send it to their

boyfriends or their girlfriends. And
when they get dumped they publish them

on these websites. So there were several
of these sites on the main internet

which have mostly been shut down.
And some of these sites were archived

on the Darknet. The second one is that
we should probably wonder what is,

is ‘abuse’. Abuse was… every single
site we classified in this category

were child abuse sites. So they were in
some way facilitating child abuse.

And how do we know that? Well, the data
that came back from the crawler

made it completely unambiguous as to what
the content was in these sites. That was

completely obvious, from then content, from
the crawler as to what was on these sites.

And this is the principal reason why we
didn’t pull down images from sites.

There are many countries that
would be a criminal offense to do so.

So our crawler only pulled down text
content from all of these sites, and that

enabled us to classify them, based on
that. We didn’t pull down any images.

So of course the next thing we liked to do
is to say: “Okay, well, given each of these

categories, what proportion of directory
requests went to each of the categories?”

Now the next graph is going to need some
explaining as to precisely what it

means, and I’m gonna give that. This is
the proportion of directory requests

which we saw that went to each of the
categories of hidden service that we

classified. As you can see, in fact, we
saw a very large number going to these

abuse sites. And the rest sort of
distributed right there, at the bottom.

And the question is: “What is it
we’re collecting here?”

We’re collecting successful hidden service
directory requests. What does a hidden

service directory request mean?
It probably loosely correlates with

either a visit or a visitor. So somewhere
in between those two. Because when you

want to visit a hidden service you make
a request for the hidden service descriptor

and that allows you to connect to it
and browse through the web site.

But there are cases where, e.g. if you
restart Tor, you’ll go back and you

re-fetch the descriptor. So in that case
we’ll count twice, for example.

What proportion of these are people,
and which proportion of them are

something else? The answer to that is
we just simply don’t know.

We've got directory requests but that doesn’t
tell us about what they’re doing on these

sites, what they’re fetching, or who
indeed they are, or what it is they are.

So these could be automated requests,
they could be human beings. We can’t

distinguish between those two things.

What are the limitations?

A hidden service directory request neither
exactly correlates to a visit -or- a visitor.

It’s probably somewhere in between.
So you can’t say whether it’s exactly one

or the other. We cannot say whether
a hidden service directory request

is a person or something automated.
We can’t distinguish between those two.

Any type of site could be targeted by e.g.
DoS attacks, by web crawlers which would

greatly inflate the figures. If you were
to do a DoS attack it’s likely you’d only

request a small number of descriptors.
You’d actually be flooding the site itself

rather than the directories. But, in
theory, you could flood the directories.

But we didn’t see any sort of shutdown
of our directories based on flooding, e.g.

Whilst we can’t rule that out, it doesn’t
seem to fit too well with what we’ve got.

The other question is ‘crawlers’.
I obviously talked with the Tor Project

about these results and they’ve suggested
that there are groups, so the child

protection agencies e.g. that will crawl
these sites on a regular basis. And,

again, that doesn’t necessarily correlate
with a human being. And that could

inflate the figures. How many hidden
directory requests would there be

if a crawler was pointed at it. Typically,
if I crawl them on a single day, one request.

But if they got a large number of servers
doing the crawling then it could be

a request per day for every single server.
So, again, I can’t give you, definitive,

“yes, this is human beings” or
“yes, this is automated requests”.

The other important point is, these two
content graphs are only hidden services

offering web content. There are hidden
services that do things, e.g. IRC,

the instant messaging etc. Those aren’t
included in these figures. We’re only

concentrating on hidden services offering
web sites. They’re HTTP services, or HTTPS

services. Because that allows to easily
classify them. And, in fact, some of

the other types are IRC and Jabber the
result was probably not directly comparable

with web sites. That’s sort of the use
case for using them, it’s probably

slightly different. So I appreciate the
last graph is somewhat alarming.

If you have any questions please ask
either me or the Tor developers

as to how to interpret these results. It’s
not quite as straight-forward as it may

look when you look at the graph. You
might look at the graph and say: “Hey,

that looks like there’s lots of people
visiting these sites”. It’s difficult

to conclude that from the results.

The next slide is gonna be very
contentious. I will prefix it with:

“I’m not advocating -any- kind of
action whatsoever. I’m just trying

to describe technically as to what could
be done. It’s not up to me to make decisions

on these types of things.” So, of course,
when we found this out, frankly, I think

we were stunned. I mean, it took us
several days, frankly, it just stunned us,

“what the hell, this is not
what we expected at all.”

So a natural step is, well, we think, most
of us think that Tor is a great thing,

it seems. Could this problem be sorted out
while still keeping Tor as it is?

And probably the next step to say: “Well,
okay, could we just block this class

of content and not other types of content?”
So could we block just hidden services

that are associated with these sites and
not other types of hidden services?

We thought there’s three ways in which
we could block hidden services.

And I’ll talk about whether these were
impossible in the coming months,

after explaining them. But during our
study these would have been impossible

and presently they are possible.

A single individual could shut down
a single hidden service by controlling

all of the relays which are responsible
for receiving a publication request

on that distributed hash table. It’s
possible to place one of your relays

at a particular position on that circle
and so therefore make yourself be

the responsible relay for
a particular hidden service.

And if you control all of the six relays
which are responsible for a hidden service,

when someone comes to you and says:
“Can I have a descriptor for that site”

you can just say: “No, I haven’t got it”.
And provided you control those relays

users won’t be able to fetch those sites.

The second option is you could say:
“Okay, the Tor Project are blocking these”

– which I’ll talk about in a second –
“as a relay operator”. Could I

as a relay operator say: “Okay, as
a relay operator I don’t want to carry

this type of content, and I don’t want to
be responsible for serving up this type

of content.” A relay operator could patch
his relay and say: “You know what,

if anyone comes to this relay requesting
anyone of these sites then, again, just

refuse to do it”. The problem is a lot of
relay operators need to do it. So a very,

very large number of the potential relay
operators would need to do that

to effectively block these sites. The
final option is the Tor Project could

modify the Tor program and actually embed
these ingresses in the Tor program itself

so as that all relays by default both
block hidden service directory requests

to these sites, and also clients themselves
would say: “Okay, if anyone’s requesting

these block them at the client level.”
Now I hasten to add: I’m not advocating

any kind of action that is entirely up to
other people because, frankly, I think

if I advocated blocking hidden services
I probably wouldn’t make it out alive,

so I’m just saying: this is a description
of what technical measures could be used

to block some classes of sites. And of
course there’s lots of questions here.

If e.g. the Tor Project themselves decided:
“Okay, we’re gonna block these sites”

that means they are essentially
in control of the block list.

The block list would be somewhat public
so everyone would be up to inspect

what the sites are that are being blocked
and they would be in control of some kind

of block list. Which, you know, arguably
is against what the Tor Projects are after.

takes a sip, coughs

So how about deanonymising visitors
to hidden service web sites?

So in this case we got a user on the
left-hand side who is connected to

a Guard node. We’ve got a hidden service
on the right-hand side who is connected

to a Guard node and on the top we got
one of those directory servers which is

responsible for serving up those
hidden service directory requests.

Now, when you first want to connect to
a hidden service you connect through

your Guard node and through a couple of hops
up to the hidden service directory and

you request the descriptor off of them.
So at this point if you are the attacker

and you control one of the hidden service
directory nodes for a particular site

you can send back down the circuit
a particular pattern of traffic.

And if you control that user’s
Guard node – which is a big if –

then you can spot that pattern of traffic
at the Guard node. The question is:

“How do you control a particular user’s
Guard node?” That’s very, very hard.

But if e.g. I run a hidden service and all
of you visit my hidden service, and

I’m running a couple of dodgy Guard relays
then the probability is that some of you,

certainly not all of you by any stretch will
select my dodgy Guard relay, and

I could deanonymise you, but I couldn’t
deanonymise the rest of them.

So what we’re saying here is that
you can deanonymise some of the users

some of the time but you can’t pick which
users those are which you’re going to

deanonymise. You can’t deanonymise someone
specific but you can deanonymise a fraction

based on what fraction of the network you
control in terms of Guard capacity.

How about… so the attacker controls those
two – here’s a picture from a research of

the University of Luxemburg which
did this. And these are plots of

taking the user’s IP address visiting
a C&C server, and then geolocating it

and putting it on a map. So “where was the
user located when they called one of

the Tor hidden services?” So, again,
this is a selection, a percentage

of the users visiting C&C servers
using this technique.

How about deanonymising hidden services
themselves? Well, again, you got a problem.

You’re the user. You’re gonna connect
through your Guard into the Tor network.

And then, eventually, through the hidden
service’s Guard node, and talk to

the hidden service. As the attacker you
need to control the hidden service’s

Guard node to do these traffic correlation
attacks. So again, it’s very difficult

to deanonymise a specific Tor hidden
service. But if you think about, okay,

there is 1.000 Tor hidden services, if you
can control a percentage of the Guard nodes

then some hidden services will pick you
and then you’ll be able to deanonymise those.

So provided you don’t care which hidden
services you gonna deanonymise

then it becomes much more straight-forward
to control the Guard nodes of some hidden

services but you can’t pick exactly
what those are.

So what sort of data can you see
traversing a relay?

This is a modified Tor client which just
dumps cells which are coming…

essentially packets travelling down
a circuit, and the information you can

extract from them at a Guard node.
And this is done off the main Tor network.

So I’ve got a client connected to
a “malicious” Guard relay

and it logs every single packet – they’re
called ‘cells’ in the Tor protocol –

coming through the Guard relay. We can’t
decrypt the packet because it’s encrypted

three times. What we can record,
though, is the IP address of the user,

the IP address of the next hop,
and we can count packets travelling

in each direction down the circuit. And we
can also record the time at which those

packets were sent. So of course, if you’re
doing the traffic correlation attacks

you’re using that time in the information
to try and work out whether you’re seeing

traffic which you’ve sent and which
identifies a particular user or not.

Or indeed traffic which they’ve sent
which you’ve seen at a different point

in the network.

Moving on to my…

…interesting problems,
research questions etc.

Based on what I’ve said, I’ve said there’s
these directory authorities which are

controlled by the core Tor members. If
e.g. they were malicious then they could

manipulate the Tor… – if a big enough
chunk of them are malicious then

they can manipulate the consensus
to direct you to particular nodes.

I don’t think that’s the case, and that
anyone thinks that’s the case.

And Tor is designed in a way to tr…
I mean that you’d have to control

a certain number of the authorities
to be able to do anything important.

So the Tor people… I said this
to them a couple of days ago.

I find it quite funny that you’d design
your system as if you don’t trust

each other. To which their response was:
“No, we design our system so that

we don’t have to trust each other.” Which
I think is a very good model to have,

when you have this type of system.
So could we eliminate these sort of

centralized servers? I think that’s
actually a very hard problem to do.

There are lots of attacks which could
potentially be deployed against

a decentralized network. At the moment the
Tor network is relatively well understood

both in terms of what types of attack it
is vulnerable to. So if we were to move

to a new architecture then we may open it
to a whole new class of attacks.

The Tor network has been existing
for quite some time and it’s been

very well studied. What about global
adversaries like the NSA, where you could

monitor network links all across the
world? It’s very difficult to defend

against that. Where they can monitor…
if they can identify which Guard relay

you’re using, they can monitor traffic
going into and out of the Guard relay,

and they log each of the subsequent hops
along. It’s very, very difficult to defend against

these types of things. Do we know if
they’re doing it? The documents that were

released yesterday – I’ve only had a very
brief look through them, but they suggest

that they’re not presently doing it and
they haven’t had much success.

I don’t know why, there are very powerful
attacks described in the academic literature

which are very, very reliable and most
academic literature you can access for free

so it’s not even as if they have to figure
out how to do it. They just have to read

the academic literature and try and
implement some of these attacks.

I don’t know what – why they’re not. The
next question is how to detect malicious

relays. So in my case we’re running
40 relays. Our relays were on consecutive

IP addresses, so we’re running 40
– well, most of them are on consecutive

IP addresses in two blocks. So they’re
running on IP addresses numbered

e.g. 1,2,3,4,…
We were running two relays per IP address,

and every single relay had my name
plastered across it.

So after I set up these 40 relays in

a relatively short period of time
I expected someone from the Tor Project

to come to me and say: “Hey Gareth, what
are you doing?” – no one noticed,

no one noticed. So this is presently
an open question. On the Tor Project

they’re quite open about this. They
acknowledged that, in fact, last year

we had the CERT researchers launch much
more relays than that. The Tor Project

spotted those large number of relays
but chose not to do anything about it

and, in fact, they were deploying an
attack. But, as you know, it’s often very

difficult to defend against unknown
attacks. So at the moment how to detect

malicious relays is a bit of an open
question. Which as I think is being

discussed on the mailing list.

The other one is defending against unknown
tampering at exits. If you took or take

the exit relays – the exit relay
can tamper with the traffic.

So we know particular types of attacks
doing SSL man-in-the-middles etc.

We’ve seen recently binary patching.
How do we detect unknown tampering

with traffic, other types of traffic? So
the binary tampering wasn’t spotted

until it was spotted by someone who
told the Tor Project. So it wasn’t

detected e.g. by the Tor Project
themselves, it was spotted by someone else

and notified to them. And then the final
one open on here is the Tor code review.

So the Tor code is open source. We know
from OpenSSL that, although everyone

can read source code, people don’t always
look at it. And OpenSSL has been

a huge mess, and there’s been
lots of stuff disclosed over that

over the last coming days. There are
lots of eyes on the Tor code but I think

always, more eyes are better. I’d say,
ideally if we can get people to look

at the Tor code and look for
vulnerabilities then… I encourage people

to do that. It’s a very useful thing to
do. There could be unknown vulnerabilities

as we’ve seen with the “relay early” type
quite recently in the Tor code which

could be quite serious. The truth is we
just don’t know until people do thorough

code audits, and even then it’s very
difficult to know for certain.

So my last point, I think, yes,

is advice to future researchers.
So if you ever wanted, or are planning

on doing a study in the future, e.g. on
Tor, do not do what the CERT researchers

do and start deanonymising people on the
live Tor network and doing it in a way

which is incredibly irresponsible. I don’t
think…I mean, I tend, myself, to give you with

the benefit of a doubt, I don’t think the
CERT researchers set out to be malicious.

I think they’re just very naive.
That’s what it was they were doing.

That was rapidly pointed out to them.
In my case we are running

40 relays. Our Tor relays they were forwarding
traffic, they were acting as good relays.

The only thing that we were doing
was logging publication requests

to the directories. Big question whether
that’s malicious or not – I don’t know.

One thing that has been pointed out to me
is that the .onion addresses themselves

could be considered sensitive information,
so any data we will be retaining

from the study is the aggregated data.
So we won't be retaining information

on individual .onion addresses because
that could potentially be considered

sensitive information. If you think about
someone running an .onion address which

contains something which they don’t want
other people knowing about. So we won’t

be retaining that data, and
we’ll be destroying them.

So I think that brings me now
to starting the questions.

I want to say “Thanks” to a couple of
people. The student who donated

the server to us. Nick Savage who is one
of my colleagues who was a sounding board

during the entire study. Ivan Pustogarov
who is the researcher at the University

of Luxembourg who sent us the large data
set of .onion addresses from last year.

He’s also the chap who has demonstrated
those deanonymisation attacks

that I talked about. A big "Thank you" to
Roger Dingledine who has frankly been…

presented loads of questions to me over
the last couple of days and allowed me

to bounce ideas back and forth.
That has been a very useful process.

If you are doing future research I strongly
encourage you to contact the Tor Project

at the earliest opportunity. You’ll find
them… certainly I found them to be

extremely helpful.

Donncha also did something similar,
so both Ivan and Donncha have done

a similar study in trying to classify the
types of hidden services or work out

how many hits there are to particular
types of hidden service. Ivan Pustogarov

did it on a bigger scale
and found similar results to us.

That is that these abuse sites
featured frequently

in the top requested sites. That was done
over a year ago, and again, he was seeing

similar sorts of pattern. There were these
abuse sites being requested frequently.

So that also sort of probates
what we’re saying.

The data I put online is at this address,
there will probably be the slides,

something called ‘The Tor Research
Framework’ which is an implementation

of a Java client, so an implementation
of a Tor client in Java specifically aimed

at researchers. So if e.g. you wanna pull
out data from a consensus you can do.

If you want to build custom routes
through the network you can do.

If you want to build routes through the
network and start sending padding traffic

down them you can do etc.
The code is designed in a way which is

designed to be easily modifiable
for testing lots of these things.

There is also a link to the Tor FBI
exploit which they deployed against

visitors to some Tor hidden services last
year. They exploited a Mozilla Firefox bug

and then ran code on users who were
visiting these hidden service, and ran

code on their computer to identify them.
At this address there is a link to that

including a copy of the shell code and an
analysis of exactly what it was doing.

And then of course a list of references,
with papers and things.

So I’m quite happy to take questions now.

applause

Herald: Thanks for the nice talk!
Do we have any questions

from the internet?

Signal Angel: One question. It’s very hard
to block addresses since creating them

is cheap, and they can be generated
for each user, and rotated often. So

can you think of any other way
for doing the blocking?

Gareth: That is absolutely true, so, yes.
If you were to block a particular .onion

address they can wail: “I want another
.onion address.” So I don’t know of

any way to counter that now.

Herald: Another one from the internet?
inaudible answer from Signal Angel

Okay, then, Microphone 1, please!

Question: Thank you, that’s fascinating
research. You mentioned that it is

possible to influence the hash of your
relay node in a sense that you could

to be choosing which service you are
advertising, or which hidden service

you are responsible for. Is that right?
Gareth: Yeah, correct!

Question: So could you elaborate
on how this is possible?

Gareth: So e.g. you just keep regenerating
a public key for your relay,

you’ll get closer and closer to the point
where you’ll be the responsible relay

for that particular hidden service. That’s
just – you keep regenerating your identity

hash until you’re at that particular point
in the relay. That’s not particularly

computationally intensive to do.
That was it?

Herald: Okay, next question
from Microphone 5, please.

Question: Hi, I was wondering for the
attacks where you identify a certain number

of users using a hidden service. Have
those attacks been used, or is there

any evidence there, and is there
any way of protecting against that?

Gareth: That’s a very interesting question,
is there any way to detect these types

of attacks? So some of the attacks,
if you’re going to generate particular

traffic patterns, one way to do that is to
use the padding cells. The padding cells

aren’t used at the moment by the official
Tor client. So the detection of those

could be indicative but it doesn't...
it`s not conclusive evidence in our tool.

Question: And is there any way of
protecting against a government

or something trying to denial-of-service
hidden services?

Gareth: So I… trying to… did not…

Question: Is it possible to protect
against this kind of attack?

Gareth: Not that I’m aware of. The Tor
Project are currently revising how they

do the hidden service protocol which will
make e.g. what I did, enumerating

the hidden services, much more difficult.
And to also be in a position on the

distributed hash table in advance
for a particular hidden service.

So they are at the moment trying to change
the way it’s done, and make some of

these things more difficult.

Herald: Good. Next question
from Microphone 2, please.

Mic2: Hi. I’m running the Tor2Web abuse,
and so I used to see a lot of abuse of requests

concerning the Tor hidden service
being exposed on the internet through

the Tor2Web.org domain name. And I just
wanted to comment on, like you said,

the abuse number of the requests. I used
to spoke with some of the child protection

agencies that reported abuse at
Tor2Web.org, and they are effectively

using crawlers that periodically look for
changes in order to get new images to be

put in the database. And what I was able
to understand is that the German agency

doing that is crawling the same sites that
the Italian agencies are crawling, too.

So it’s likely that in most of the
countries there are the child protection

agencies that are crawling those few
numbers of Tor hidden services that

contain child porn. And I saw it also
a bit from the statistics of Tor2Web

where the amount of abuse relating to
that kind of content, it’s relatively low.

Just as contribution!

Gareth: Yes, that’s very interesting,
thank you for that!

applause

Herald: Next, Microphone 4, please.

Mic4: You then attacked or deanonymised
users with an infected or a modified Guard

relay? Is it required to modify the Guard
relay if I control the entry point

of the user to the internet?
If I’m his ISP?

Gareth: Yes, if you observe traffic
travelling into a Guard relay without

controlling the Guard relay itself.
Mic4: Yeah.

Gareth: In theory, yes. I wouldn’t be able
to tell you how reliable that is

off the top of my head.
Mic4: Thanks!

Herald: So another question
from the internet!

Signal Angel: Wouldn’t the ability to
choose the key hash prefix give

the ability to target specific .onions?

Gareth: So you can only target one .onion
address at a time. Because of the way

they are generated. So you wouldn’t be
able to say e.g. “Pick a key which targeted

two or more .onion addresses.” You can
only target one .onion address at a time

by positioning yourself at a particular
point on the distributed hash table.

Herald: Another one
from the internet? … Okay.

Then Microphone 3, please.

Mic3: Hey. Thanks for this research.
I think it strengthens the network.

So in the deem (?) I was wondering whether
you can donate this relays to be a part of

non-malicious relays pool, basically
use them as regular relays afterwards?

Gareth: Okay, so can I donate the relays
a rerun and at the Tor capacity (?) ?

Unfortunately, I said they were run by
a student and they were donated for

a fixed period of time. So we’ve given
those back to him. We are very grateful

to him, he was very generous. In fact,
without his contribution donating these

it would have been much more difficult
to collect as much data as we did.

Herald: Good, next, Microphone 5, please!

Mic5: Yeah hi, first of all thanks
for your talk. I think you’ve raised

some real issues that need to be
considered very carerfully by everyone

on the Tor Project. My question: I’d like
to go back to the issue with so many

abuse related web sites running over
the Tor Project. I think it’s an important

issue that really needs to be considered
because we don’t wanna be associated

with that at the end of the day.
Anyone who uses Tor, who runs a relay

or an exit node. And I understand it’s
a bit of a censored issue, and you don’t

really have any say over whether it’s
implemented or not. But I’d like to get

your opinion on the implementation
of a distributed block-deny system

that would run in very much a similar way
to those of the directory authorities.

I’d just like to see what
you think of that.

Gareth: So you’re asking me whether I want
to support a particular blocking mechanism

then?

Mic5: I’d like to get your opinion on it.
Gareth laughs

I know it’s a sensitive issue but I think,
like I said, I think something…

I think it needs to be considered because
everyone running exit nodes and relays

and people of the Tor Project don’t
want to be known or associated with

these massive amount of abuse web sites
that currently exist within the Tor network.

Gareth: I absolutely agree, and I think
the Tor Project are horrified as well that

this problem exists, and they, in fact,
talked on it in previous years that

they have a problem with this type of
content. I asked to what if anything is

done about it, it’s very much up to them.
Could it be done in a distributed fashion?

So the example I gave was a way which
it could be done by relay operators.

So e.g. that would need the consensus of
a large number of relay operators to be

effective. So that is done in
a distributed fashion. The question is:

who gives the list of .onion addresses to
block to each of the relay operators?

Clearly, the relay operators aren’t going
to collect themselves. It needs to be

supplied by someone like the Tor Project,
e.g., or someone trustworthy. Yes, it can

be done in a distributed fashion.
It can be done in an open fashion.

Mic5: Who knows?
Gareth: Okay.

Mic5: Thank you.

Herald: Good. And another
question from the internet.

Signal Angel: Apparently there’s an option
in the Tor client to collect statistics

on hidden services. Do you know about
this, and how it relates to your research?

Gareth: Yes, I believe they’re going to
be… the extent to which I know about it

is they’re gonna be trying this next
month, to try and estimate how many

hidden services there are. So keep
your eye on the Tor Project web site,

I’m sure they’ll be publishing
their data in the coming months.

Herald: And, sadly, we are running out of
time, so this will be the last question,

so Microphone 4, please!

Mic4: Hi, I’m just wondering if you could
sort of outline what ethical clearances

you had to get from your university
to conduct this kind of research.

Gareth: So we have to discuss these
types of things before undertaking

any research. And we go through the steps
to make sure that we’re not e.g. storing

sensitive information about particular
people. So yes, we are very mindful

of that. And that’s why I made a
particular point of putting on the slides

as to some of the things to consider.

Mic4: So like… you outlined a potential
implementation of the traffic correlation

attack. Are you saying that
you performed the attack? Or…

Gareth: No, no no, absolutely not.
So the link I’m giving… absolutely not.

We have not engaged in any…

Mic4: It just wasn’t clear
from the slides.

Gareth: I apologize. So it’s absolutely
clear on that. No, we’re not engaging

in any deanonymisation research on the
Tor network. The research I showed

is linked on the references, I think,
which I put at the end of the slides.

You can read about it. But it’s done in
simulation. So e.g. there’s a way

to do simulation of the Tor network on
a single computer. I can’t remember

the name of the project, though.
Shadow! Yes, it’s a system

called Shadow, we can run a large
number of Tor relays on a single computer

and simulate the traffic between them.
If you’re going to do that type of research

then you should use that. Okay,
thank you very much, everyone.

applause

silent postroll titles

subtitles created by c3subtitles.de
Join, and help us!