Tor onion services: more useful than you think

32C3 preroll music

Herald: I welcome you to “TOR Onion
Services – more useful than you think!”

This talk is presented by George

– who is a core developer of TOR and he is
also a developer of the Hidden Services –

by David Goulet – who is a developer
for the TOR Hidden Services –

and by Roger, who is founder of the
TOR Project, an MIT Graduate and

the Foreign Policy Magazine
calls him: he is one of the

Top 100 Global Thinkers.
I think that speaks for himself.

applause

Today we will hear examples of Hidden
Services for really cool use cases,

but also we will hear about security
fixes that make the Hidden Services

even more safer and
stronger for all of us.

Stage free for “TOR Onion Services –
more useful than all of us think”

applause
Roger: Great!

Hi, I’m going to pause while
we get our slides up, I hope…

Hopefully that will be a quick
and easy event – perfect!

Okay, so. Hi, I’m Roger,
this is George, this is David.

We’re going to tell you about TOR Hidden
Services or TOR Onion Services.

They’re basically synonyms, originally
they were called TOR Hidden Services

because the original idea was that
you hide the location of the service;

and then a lot of people started
using them for other features,

other security properties, so we’ve been
shifting to the name Onion Services.

So we’ll switch back and
forth in what we call them.

So, a spoiler before we start.
This is not a talk about the dark web,

there is no dark web.
It’s just a couple of

websites out there that are protected
by other security properties.

So we’ll talk a lot more about
that. You can think of it as:

HTTPS is a way of getting encryption and
security when you’re going to a website

and .onion is another way of getting
encryption and security when you’re

going to a website. So, journalists
like writing articles about the

huge iceberg with 95% of
the web is in the dark web.

That’s nonsense! So we’re gonna try
and tell you a little bit more about

what actually is Hidden Services
and Onion Services and

who uses them and what
things they can do with them.

How many people here know
quite a bit about how TOR works

and what TOR is and so on? I’m
hoping everybody raises their hand!

Awesome, okay. We can
skip all of that, perfect!

So TOR is a US non-profit,

it’s open-source, it’s a
network of about 8000 relays.

One of the fun things about TOR is the
community of researchers, and developers,

and users, and activists, and
advocates, all around the world.

Every time I go to a new city, there’s
a research group at the university

who wants me to teach them what
the open research questions are

and how they can improve, how
they can help you improve TOR.

So, the basic idea is,
you have your software,

it pulls down a list of the 8000 relays,

and it builds a path through 3 of them

so that no single relay gets to learn

where you’re coming from
and where you’re going.

And you can see up at the top
here, there is a .onion address.

So basically Hidden Services,
or Onion Services, are

in your browser, in your TOR browser,
you go to an alternate type of

domain name, that ends in .onion,
and then you end up at that website.

So here’s an example of
a riseup.net website,

which we are reaching using
the onion address for it

rather than black.riseup.net.

Okay, so, I talked about the building
block before, how you use TOR normally

to build a 3-hop circuit through the
network. Once you have that building block,

then you can glue two of them together.

So you’ve got Alice over here,
connecting into the TOR network,

and you’ve got Bob, the website,
connecting into the TOR network,

and they rendez-vous in the middle.

So Alice is getting her anonymity,
her 3 hops inside TOR,

Bob is getting his anonymity,
his 3 hops inside of TOR,

and they meet in the middle.

So Alice doesn’t know where Bob is,
Bob doesn’t know where Alice is,

and the point in the middle
doesn’t know either of them,

yet they can reach each other, and
get some cool security properties.

So, some of these cool
security properties:

One of the really cool ones is that
that .onion name that you saw

with the base32

big pile of 16 characters,

that is the hash of the public
key which is the Onion Service,

which is the Onion address.
So they’re self-authenticating, meaning

if I have the right onion address,

I can be sure that I’m
connecting to the website,

to the service, that’s
associated with that key.

So I don’t need some sort
of Certificate Authority model

where I trust Turkish
Telecom to not lie to me.

It’s all built-in, self-authenticating,

I don’t need any external resources

to convince myself that I’m
going to the right place.

Along with that, is, they’re
end-to-end encrypted.

So I know that nobody
between my TOR client

and the TOR client on the
Service side is able to read,

or intercept, or
man-in-the-middle the traffic.

So there are some other
interesting features also,

one of them is the NAT punching feature.

If you offer an Onion Service,

there’s no reason to allow
incoming connections to it.

So I can run an Onion Service
deep inside the corporate firewall,

or behind Comcast’s firewall,
or wherever I want to,

and people are able to reach it.

So there are a lot of people from
the systems administration side

who say: “I’m going to offer an Onion
address for my home SSH server,

and now the only way that I can
connect back into my home box

is via the TOR network.
I get end-to-end encryption,

I get self-authentication,
and there’s no other way in.

I just firewall all incoming connections

and so the only surface area
that I expose to the world

is, if you’re using my onion
address, you reach my SSH port.

I don’t allow any other
packets in of any sort.”

So that’s a cool example
of how security people

use Onion Services.

George: So, hello, we have some
statistics for you to show you,

to give you an idea of the
current maturity of the system.

We got these statistics by asking
relays to send us information

about the Hidden Service
activity they see.

Only a small fraction of relays
is reporting these statistics,

so we extrapolate
from this small fraction.

So that’s why these statistics can
have lots of ups and downs,

and noise, and everything, but anyway,
they can give you a basic idea.

So, this first statistic is the number of
Hidden Services on the network,

and you can see that it’s about
30.000 Hidden Services, give or take,

and it’s a pretty small number if you
compare it to the whole Internet,

I don’t even know, it’s basically
in the early adoption stages.

And we also have
another statistic, this one,

which is the traffic that the Hidden
Services are generating, basically.

On the top, you can see the total traffic
that the whole network is pushing.

It’s about, I don’t know, 60.000 megabits,

and the bottom graph is the
Hidden-Service-specific traffic,

and you can see that
it’s like 1000 megabits.

Like, a very small
fraction, basically. So,

Hidden Services are still a
very small part of TOR. And,

if you don’t understand this
number thing very well,

we did some calculations and stuff,
and we have this new figure for you,

which is that basically 5% of
client traffic is Hidden Services.

From the whole TOR, 5% is
Hidden Services, basically.

You can handle this as you want.

So, and, we did this whole
thing like a year ago,

and we spent lots of time like figuring
out how to collect statistics,

how to get from the values
themselves to those graphs,

how to obfuscate the statistics in
such a way that we don’t reveal

any information about any clients,

and we wrote a tech report about
it, that you can find in this link

if you’re interested in looking more
[at] how the whole thing works,

and we even wrote a proposal, so if you
google for TOR Project, proposal 238,

you can find more information,
and, yeah, that’s it.

Roger: Okay, so, how did
this whole thing start?

We’re going to go through a
couple of years at the beginning.

In 2004, I wrote the original
Hidden Service code,

and I basically wrote it as a toy.

It was an example: “We
have this thing called TOR,

and use it as a building
block, look what we can do!

We can connect 2 TOR circuits together,

and then you can run a service like this.”

Basically nobody used it for a few years.

One of my friends set
up a hidden wiki where,

if you run an Onion Service,
then you can go to the wiki,

and sign up your address
so that people can find it.

And there were some example services.
But for the first couple of years,

it basically wasn’t used,
wasn’t interesting.

The first really interesting use
case was the Zyprexa documents.

So this was in 2005, 2006.

There’s a huge pharmaceutical
company called Eli Lilly

and they have an antipsychotic
drug called Zyprexa

and it turns out that it was
giving people diabetes

and harming them, and killing
them, and they knew about it.

And somebody leaked 11.000
documents onto the Internet

showing that this drug
company knew about the fact

that they were harming their customers.

And of course the drug company sent
a cease and desist to the website,

and it went away, and it
came up somewhere else,

and they sent a cease and desist,
and it was bouncing around,

and suddenly somebody set up a TOR
Hidden Service with all of the documents,

and Eli Lilly had no idea how to send
a cease and desist to that address,

and a lot of people were able to read

the corruption and problems
with this drug company.

So that was… on the one hand, yay!

applause

On the one hand, that’s really cool. Here
we are, we have a censorship-resistant

privacy thing, somebody
used it to get information out

about a huge company that
was hurting people, great!

On the other hand, it set
us up where ever after,

people looked at Hidden Services and said:

“Well, how do I find a document
that some large organization’s

going to be angry about? I’m going
to set up a website for leaking things,

I’m gonna set up a website for something
else that the Man wants to shut down.”

So the first example of
Hidden Services pointed us

in a direction where, after
that, a lot of people

thought that that’s what
Hidden Services were about.

So, that leads to the next year,

Wikileaks set up a Hidden Service
for their submission engine,

and it’s not that they wanted to
hide the location of the server.

The server was in Sweden, everybody
knew the server was in Sweden.

But they wanted to give extra security
to users who were trying to get there.

One of the really interesting properties
that they used from Hidden Services

is the fact that if you
go to the .onion site

from your normal browser,
it totally doesn’t work.

And this was a security feature for them.

Because they wanted to make
sure that if you’re a leaker,

and you’re doing it wrong,
you’re configuring things wrong,

then it totally fails from the beginning.

They wanted to completely remove
the chance that you accidentally think

that you’re using TOR
correctly and being safe

when actually you screwed
up and you’re not using TOR.

So they wanted to use Onion Services

as another layer of security for the user,

to protect the user from screwing up.

Now fast forward a couple of more years,
there’s another organization in Italy

called GlobaLeaks, where they’ve
set up basically a mechanism where,

if you have something you
want to share with the world,

then you can be connected to a journalist
through this GlobaLeaks platform.

And they actually have been
going around to governments,

convincing them to set
up GlobaLeaks platforms.

So they’ve gone to the Italian government,

they’ve gone to the Philippine government,

and basically they say:
“Look, this is a way for you

to report on corruption,
to hear about corruption

inside your country.” Now, if you
go to a government, and you say:

“I hear there is corruption,
here’s a way to report on it.”

not everybody in the government
will be happy with that.

But one of the features is,
you can very easily say:

“Can you help me set up an
anti-corruption whistleblowing site

for the country next door? I would be
happy to… you know they’ve got corruption,

so how about they provide
the corruption site?”

applause

So it’s really cool that GlobaLeaks
is playing the political game,

trying to demonstrate that making
these things public is worthwhile.

And, of course, here’s a picture of a
cute cat, we have to have one of those,

and WildLeaks is a really
good example of a positive,

I mean, this is a way where if you
see somebody killing a rhinoceros

or elephant or something in
Africa, and you know about it,

upload it to WildLeaks, and
then they can learn more

about poaching and
extinction events and so on.

So, it’s hard to argue with anti-poaching,

anti-corruption sites like that.

And that moves us to SecureDrop,
there’s a group in the US

that is working on another
example of how to connect

people with interesting information
to journalists who want to write about it.

And they’ve actually connected
with the New Yorker and a lot of

high-profile newspapers,

to be able to provide a way for people
to securely provide information

to those journalists. And they say that
it has been used in high-profile events,

and they won’t tell us which
events, which is great!

That’s exactly how it’s
supposed to work.

applause

David: Hello. So, continuing
our timeline here,

this very cool thing happened
in 2014, where Aphex Twin,

this electronic experimental guy,

released his album Syro through
an onion address on Twitter,

and he got 4.000 Retweets.
So we encourage you guys

to consider this method
of releasing all your stuff,

and the complementary ways to
release it would be the open web.

So, onion addresses.

Following that, we got
Blockchain, recently,

in 2014, let’s say two years ago.

They discovered that
for security concerns,

when you’re using TOR, the exit nodes,

some exit nodes, and malicious exit nodes,

were rewriting the Bitcoin addresses.

So for security concerns, they changed…

if you go… you come to
blockchain.info from TOR,

they tell you to use the onion address

so you get all the fancy properties
of end-to-end encryption,

and so on, and so forth.

As of still today, we know
that malicious exit nodes exist,

and they do rewrite Bitcoin addresses.

Don’t be alarmed, it’s not like HAL3000’s,

the thing is that, we at the TOR
Project are actively monitoring

the network at the exit nodes

for these kinds of craziness.

And we need more help from
everyone, from the community,

to find those, so we can block them,

remove them, so fuck
those. Fuck those guys.

And Blockchain took action
with Onion Services. So, great.

Roger: And Facebook set up a
Hidden Service recently as well,

an onion address for their website.

So, the first thing many of
you might be thinking is:

“Wait a minute, I don’t understand,
Facebook is a website on the Internet,

why do they need a Hidden Service,
why do they need an onion address?”

So, the first answer is, they worry
about users in interesting countries.

Say you’ve got a Facebook user in
Turkey or Tunisia or something like that,

and they try to go to Facebook,

and the local DNS server lies to them
and sends them somewhere else,

or Turkish Telecom, which is a certificate
authority that everybody trusts,

ends up pretending to be Facebook.

You man-in-the-middle them,
now there’s certificate pinning

and other challenges like that,
and maybe those are good starts.

But wouldn’t it be cool just to skip the
whole certificate authority infrastructure

and say “Here’s an address”, where
if you go to this in your TOR Browser,

you don’t have to worry
about PGP hijacking,

you don’t have to worry
about certificate authorities,

you don’t have to worry about DNS,
it’s all inside the TOR network,

and it takes care of the security
properties I talked about before.

So, that’s a really cool
way that they can switch.

I was talking to one of the
Facebook people earlier.

He doesn’t want me to tell the number of
users who are using Facebook over TOR,

but it’s many hundreds of thousands.
It’s a shockingly high number of users.

So, wouldn’t it be cool if we
can switch many of those users

from connecting to Facebook.com over TOR,

to connecting to Facebook’s onion address,

and then reduce the
load on the exit relays,

so that it’s faster and
easier and scales better

for the people connecting to websites
that aren’t onion addresses?

So, I was thinking about
this at the very beginning

and I was thinking: “Wait
a minute, I don’t get it,

Facebook has an onion address,
but they have a real address,

why do we need the other one?”
And then I was thinking back.

So, you remember 10 years ago,
when people were running websites

and the administrator on the website said:

“I don’t need to offer HTTPS for
my website, because my users…”

and then they had some bullshit excuse
about how their users didn’t need security

or didn’t need encryption,
or something like that.

And now, 10 years later, we all think

that the people saying: “I don’t
need HTTPS for my website”…

we think they’re greedy and
short-sighted, and selfish,

and they’re not thinking
about their users.

I think the Onion Service thing
is exactly the same thing.

Right now, there are
plenty of people saying:

“I already have HTTPS, I don’t need
an onion address for my website

because my users…” and then
they have some lame explanation.

So hopefully in a couple of years,
it will be self-evident to everybody

that users should be the ones to choose

what sort of security
properties they want.

It shouldn’t be about what the
website thinks the user should have.

I should have the choice
when I’m going to Facebook.

Do I go to the HTTP version,
do I go to the HTTPS version,

do I go the onion version?

It should be up to me to
decide what my situation is

and get the security
properties that I want.

The other challenge here, I’ve talked
to some researchers a while ago

who said: “I found a copy of
Facebook on the dark web”

and I was thinking: “Wait a minute,

you didn’t find a copy of
Facebook on the dark web,

there’s a mechanism for securely
getting to the website called Facebook,

and it’s called Onion Services.

There’s no separate dark web,
it’s about transport encryption,

it’s about a way of reaching
the destination more safely.”

One of the other really cool things,

Facebook didn’t just set
up an onion address,

they got an HTTPS certificate
for their onion address.

They got an EV cert,
the kind that shows you

the green little bar that says:
“This is Facebook”

for their onion address.
They went to Digicert,

and Digicert gave them an SSL certificate

for their onion address, so now you can
get both of them at once. Which is

an amazing new step that we hadn’t
even been thinking about at the time.

So, what does this give them?
Why is this valuable?

One of them is, on the browser side,

when you’re going to an HTTPS URL,

the browser knows to
treat those cookies better,

and to not leak certain things,

and there’s all sorts of security
and privacy improvements

that browsers do when you’re going there.

And we don’t want to teach the browser

that if it’s HTTPS or .onion then be safe.

The other nice thing, on the server side,

Facebook didn’t have to change anything.

This is another way of reaching
the Facebook server.

That’s all there is to it.

And then, another cool thing:

It turns out that the only way
to get a wildcard EV certificate

is for an onion domain.

It’s actually written into, like,
the certificate authority world,

that there is a grand exception
for onion addresses.

You can’t get a wildcard EV cert
unless it’s for an onion address.

So this is super duper
endorsement of Onion Services

from the certificate authority people.

applause

But let’s take a step even further.

Wouldn’t it be cool if we take
the Let’s Encrypt project

and they bundle a TOR client in

with each web server that’s
offering the Let’s Encrypt system?

So every time you sign up for Let’s
Encrypt, you also click the button

saying: “And I want an onion
address for my website”,

and they automatically,
in the same certificate…

you get one for riseup.net,
and as an alternate name,

it’s blahblahblah.onion.
It’s in the same certificate.

So users can go to your website directly

or they can go there
over the onion address

and either way you
provide the SSL certificate

that keeps everybody safe.

Wouldn’t it be cool if every time
somebody signs up for Let’s Encrypt,

they get an onion address
for free for their website,

so that everybody can choose how
they want to reach that website?

applause, cheering

Now, there are a few problems
with that. One of the big ones is,

we want some way of binding
the riseup.net address

to the onion address,
so that when I go to riseup.net

I know that I’m going to
the correct onion address.

So we need some way to vouch for them

and connect them through
signatures or something.

It can be done, but somebody
needs to work out the details.

The other policy barrier is,

right now, the certificate
authority people

say you cannot get an
onion address for a DV cert,

the normal kind of cert.
You can only get it for an EV cert.

And Alec over here is leading the charge

to convince them that that makes no sense,

so hopefully in the next couple
of years, with all of your help,

they will realize that onion addresses are

just like all the other
addresses in the world.

Which leads to another really
cool feature from this year.

We got IETF to publicly
specify, in a real RFC,

that the .onion domain is a special case,

and they’re not going to give
it out in any other way. So…

applause
yeah!

applause

So the first effect here is
that we have actual approval

of Onion Services from the IETF
and other standards committees.

But the second effect, which
is a second-order effect, is,

now we can go to the browsers,
and the DNS resolvers,

and say, whenever you
see an onion resolve,

cut it right there, because you
know that it’s not going into TOR,

and you know that it shouldn’t
go out onto the network.

So now, when you’re in your
normal Internet Explorer,

and you accidentally click
on an onion address,

Internet Explorer knows
that that’s a local address,

that shouldn’t go out onto the network.

So we can keep people
safer, in ordinary browsers

that otherwise wouldn’t
even care that we exist.

George: OK, so, so far we’ve been talking
about websites and Hidden Services,

but this is not all that
Hidden Services can do.

Basically, you can do any sort of TCP

thing you want to do over Hidden Services.

We’re going to show you a few
examples of third-party applications

that have been developed
for Hidden Services

and do various interesting things.

First of all, OnionShare is
a file transfer application

where you basically download this
thing, and then you feed it a file,

and then it exposes a HTTP
server that you can,

that basically hosts your file, an
onion address that hosts your file,

and you can give that a URL, you
can give that URL to your friends,

and they can just put it on their TOR
Browser and download the file easily.

It’s quite convenient, nicely made,

and I think various organizations

like the Intercept and stuff, are
using it to transfer files internally.

And it works fine so far,
as far as we know.

Then the various Hidden Services
are quite good for doing messaging

because basically both sides are anonymous

and this gives a nice twist to
when you talk to some person

and one way to do so is Ricochet,

which is an application that allows you

to talk one-to-one to other people.

It’s decentralized, because
it works over Hidden Services.

That’s actually quite useful,
because, for example,

a few months ago, the Jabber CCC
server got shut down for a few days

and you couldn’t talk
to anyone, basically,

but if you used Ricochet, you were fine,

because they can shut down the CCC server

but they probably can’t shut down
the whole TOR network so easily.

It also has a nice slick UI,
which is quite refreshing

if you’re used to the usual
UIs of the open-source world.

And, anyway, you can…

you can download it from
that web server there.

And then there is Pond,

which is a more experimental
avant-garde messaging application,

which is basically a mix between
messaging and mix nets.

It basically uses a server which
delays your messages and stuff,

which makes it much harder
for a network adversary

to know when you’re sending
or receiving messages,

because you also send chaff,
and fake traffic and stuff.

It’s super-experimental,

the author doesn’t even
want us to really endorse it,

but information is free and
you can visit that website

to learn more about it.

David: So, there’s also,
for many years now,

plenty of services and tools that exist.
George just showed us some tools,

but now there’s services like
Jabber, SMTP, and IMAP,

from the Riseup guys, but not
only Riseup, but Systemli,

Autistici, and Calyx Institute for Jabber.

And it’s more and more and
more Jabber servers right now

that are federating TOR through the Onions

for server-to-server
and also client-to-server.

And this has been around for a long time,
and it serves many, many, many users.

I think Riseup has more than
30.000 users on their Jabbers.

Another neat thing about them is,

very recently, that Debian
created their package repository

and now you can use an onion address
to just update your Debian system.

And you use this amazing package
which is apt-tor-transport and, hop!,

you can update everything through an onion
address, it will detect it automatically.

But then, there’s also much
more that happened recently.

Also the GPG key servers
exist as an onion address.

So you can update your GPG key,

and download a signature,
and so on, and so forth,

which in a way hides
from global observers,

because we know they exist,
all your social graph

because, well, you’re in an
end-to-end encrypted channel.

Of course it can go to
GPG servers, that’s true,

but still at least on the
wire, it’s hidden. Very nice.

Now, DuckDuckGo of course, they have
Jabbers and they also have Hidden Service.

And I talked to the DuckDuckGo
people a few months ago maybe,

I don’t remember. But the point is,
they have many, many, many users

coming through their onion
addresses. The Pirate Bay also.

So, the point of all this is that,
with Facebook and Blockchain,

and all those we’ve seen
– and we actually know that

several Alexa 500 top websites

are currently deploying onion addresses.

And the point here is, between
the TOR network, the onion space

and the open Internet…
If all sites are on both sides, well,

it becomes one side. It’s just different
ways of accessing the information.

So please, please, please go to your
companies, go to your organization,

deploy onion addresses,
and make them public.

Help us have much more.

Roger: Let me, before I get to
the next one, re-emphasize

the point that George was
making about Ricochet.

So Ricochet is an alternate chat program

where every user is
their own onion address.

Every user is their own Onion Service.

And you talk from one Onion
Service to the other Onion Service.

You don’t have to know where the person is
or necessarily even who the person is.

And there’s no middle,
there’s no central point

to go and learn all the accounts,

and who’s friends with who, and so on.

There’s nothing to break into in the
middle where you can spy on everybody.

Everything is decentralized,
everybody is their own onion address.

So I think that’s a key point
as an alternate chat paradigm

where hopefully we can switch away
from the centralization model.

applause

Okay. So, on to phase 2,
a brief diversion.

We’ve been talking to a bunch of
researchers over the past few years

about, they want to do
research on TOR to study

how many users there are,
or how many people go to Facebook,

or all sorts of other
research questions, and

sometimes they do it in dangerous
ways, or inappropriate ways.

So we’ve been working on guidelines
to help people who want to do it safely

actually be able to not harm
people or minimize the harm.

So here are some of the guidelines.

First one is, try to attack your
own traffic, try to attack yourself,

so, if you have a question and you
need to do it on the real TOR network,

you should be the one to generate
your traffic and then try to attack that.

You shouldn’t just pick an
arbitrary user and attack them

because who knows if that’s a
person in Syria who needs help

or a person in Germany who’s trying to
get out from oppression, and so on.

Another approach: only collect data that
you’re willing to publish to the world.

So, too many researchers say:

“Well I’m going to learn all
of this interesting stuff,

and I’m going to write it
down on my hard drive,

and I’ll keep it very safe.
Nobody will break in.”

That approach fails every time.

Somebody breaks in, you lose
the data, you forget about it,

so the ethical way to do this is,

only collect stuff that you’re
willing to make public.

Only collect stuff that’s
safe to make public.

And then the other piece, that’s part
of what we’re talking about there,

don’t collect data that you don’t need,

so figure out what your
research question is,

figure out the minimum that you
can collect to answer that question.

For example, if I want to know
how many people connect to Facebook,

I should not collect every destination
that everybody goes to,

and then afterwards count up
how many of them were Facebook.

I should have a counter that
says: Facebook, increment.

And then at the end it outputs a number,

and that’s the only thing that
I need to know in that case.

So limit the granularity of data.

If you’re counting how many users
are connecting from different countries,

and there are very few
users coming from Mauritania,

consider rounding that down to zero,

so that you don’t accidentally harm

the five people in Mauritania
who’re using it today.

So, approach to do this is:

figure out what you’re trying to learn,

describe the benefits to
the world of learning that,

describe the risks to
people around the world

in TOR of the approach that you’re taking,

and then argue that the benefits
are outweighing the risks.

And one of the key ways
of looking at this is,

if you’re collecting something
interesting, some interesting dataset,

think about whether there
could be somebody else,

somewhere out there in the world,
who has some other dataset,

and when you combine
their dataset with yours,

somebody learns something new,
somebody gets harmed.

If you can imagine any other dataset

that, when it’s combined
with yours, harms people,

then you need to think harder about that.

And then the last point:
use a test network, when possible.

There’s a tool called chutney,
there’s a tool called Shadow,

where you can run your own internal
TOR network on one computer,

and if you can do your research
that way, it’s even better.

So, those are great
guidelines, sounds good.

We need to encourage
more people to do them,

and, to be fair, this is not going to

stop bad people from doing bad things.

But if you want to do
research responsibly,

and ethically, without harming TOR users,

then we need to help everybody learn

what the guidelines are
to do it more safely.

So here’s an example of a tricky edge case

where we really want to think
harder about these things.

One of them is, there are people out there

who want to build a list of every
onion address that they can find.

So, you can learn about
that by going to google

and doing a google search on .onion
and they give you some addresses.

That’s okay, that seems reasonable.
It’s a public dataset, okay, fine.

There’s a more complicated
one, where you are Verisign,

and you run some of the DNS root servers,

and you spy on the DNS
queries of the whole Internet.

And anybody who accidentally
sends a .onion DNS query

to your root server, you write it down.

So now you learn all the side-channel

accidentally leaked addresses.

Is that, does that follow our guidelines?
Is that okay, is that ethical?

It’s kind of complicated,
but I don’t know a way to stop it,

and they already have
the dataset. So, okay, fine.

Now a more complicated one.

What if you’re Comcast, and
you spy on all of your users,

to find out what their DNS queries are,
to learn about accidental leakage there.

Again, I’m going to say it’s
complicated, but it’s probably fine,

they’re already seeing it,
there’s nothing we, TOR, can do

to change our protocol, to make
people accidentally leak these things.

But then option four:

what if you want to learn
a bunch of onion addresses,

so you run new relays in the TOR network,

and you sign them up and
they get into a position

where they can learn about onion addresses

that are being published,
and then you make a list internally.

So that’s actually not cool, because

it’s part of the TOR protocol

that people providing onion addresses

don’t expect those to become public,

and we’ll talk later about
ways that we have

for being able to fix this.

So, if it’s a protocol problem
that we know how to fix,

and it’s inside TOR, and
you’re misbehaving as a relay,

then that’s not cool.
So this is an example where,

it’s sort of hard to reason through
where we should draw the line,

and I’d love to chat more
with you all after that

about where the line should be.

And that leads to an example

of some research that was done last year,

by, we think, some folks at CMU,

who attacked the TOR network,

and, as far as I can tell,
collected a dataset,

and they collected more than they needed

to answer their research questions.

They didn’t do minimization,

they didn’t attack only their own traffic,
they didn’t use a test network,

they basically violated every one of
the guidelines from two slides ago.

So that’s sort of a sad story,

and that leads to the next question:

Should we have some sort
of TOR ethics review board?

Wouldn’t it be cool if, as a researcher,

you write up what you’re trying to learn

and why it’s safe,
and how you’re going to do it,

and you show that to other professors
who help you decide whether you’re right,

and then we go to the academic
review journals and conferences,

and we get them to expect,
in your research paper,

a little section on why this
is responsible research.

And, at that point, it’s expected
that you have thought through that,

and anybody who writes a
paper without that section,

everybody knows that they haven’t
thought it through as much as they should.

Wouldn’t that be a cool future world
where research is done more responsibly

around TOR, and around
security more generally?

applause

Okay. So, there are a couple of problems

in TOR Onion Service security right
now. I’m gonna zip through them briefly

so we can actually get to talk about
them in more detail. The first one is,

the onion identity keys are RSA 1024 bits.

So, that is too short.
We need to switch to ECC.

Another one is, you, the adversary,

can run relays, and
choose your identity key

so that you end up in the
right place in the network

in order to target – censor,
surveil, whatever –

certain onion addresses.
And we’ll talk more about that also.

Another one, I talked about
that a few slides ago,

you can run relays in order to
learn about new onion addresses,

and we’ve got some fixes for that.

So those are 3 that
are onion-address specific,

onion-service specific, that we can solve.

And then there are 3 issues
that are much more broad.

One of them is,

bad guys can run hundreds of relays,

and we need to learn how to
notice that and protect against it.

Another one is,

you can run relays to learn more about

the path selection that
clients are going to do,

and then there’s website fingerprinting.
All of those are separate talks.

I wanted to mention them here,
I’m happy to talk about them later,

but we don’t have time
to get into them in detail.

Okay, phase three, how
do TOR Hidden Services,

TOR Onion Services work right now?
Just to give you some background,

so that when we talk about
the design improvements,

you have a handle on what’s going on.

So, we’ve got Alice over here, she
wants to visit some Hidden Service Bob.

The first step is, Bob generates a key,

and he establishes 3 introduction points,

3 circuits into the TOR network.

And then he publishes, to
the big database in the sky,

“Hi, this is my key,

and these are my 3 introduction points.”

And at that point, Alice somehow
learns his onion address,

and she goes to the database
and pulls down the descriptor

that has his key and the
3 introduction points

and in parallel to that,
she connects to the –

she picks her own rendezvous point,
and she builds a TOR circuit there.

So at this point, Bob has 3 introduction
points open in the TOR network,

and Alice has one rendezvous
point open in the TOR network.

And at that point, Alice connects
to one of the introduction points

and says: “Hey, I want to connect
to you, and I’m waiting over here.

This is the address for
my rendezvous point.

If you want to talk back to me,
I’m waiting right here.”

And then at that point,
Bob, if he wants to,

makes a connection to
the rendezvous point.

So now Alice has a connection
to the rendezvous point,

and Bob has a connection
to the rendezvous point,

and at that point they do
the crypto handshake

so that they get end-to-end encryption,

and then, as the last step,
they’re able to send traffic

over that circuit, where Alice has 3 hops,

and Bob has three hops,

and they’re able to provide
security from that point.

So that’s a very brief summary

of how the handshake works,

in Hidden Service land.

So, in the previous slide, I was talking
about this database in the sky.

Once upon a time, that
was just 3 computers.

I ran 2 of them.

Another directory authority
operator ran the third.

And then, we switched to distributing
that over the entire TOR network,

so there are 8000 relays…

So imagine the hash of each relay’s
identity key on this hash ring.

There are 6 relays at any given point

that are responsible for knowing

where a given Onion Service is.

So, when I’m running my own Onion Service,

I compute which 6 relays they are,

and I publish my descriptor to it,

and when I’m the client
and I want to go there,

I compute which 6 relays they are,

and I go to any one of them,
and I can fetch the descriptor.

So, the way that we actually generate

the predictable set of
which relays they are,

is this hash function up on the top.
So you look at the onion address,

you look at what day
it is, the time period,

and other things that are pretty static.

So that’s how both sides can compute

which relays they should go to

when they’re publishing
or fetching a descriptor.

George: Okay, so, back to
the security issues again.

A few years ago, like 2..3 years ago,

we started looking into Hidden Services

and enumerating the various problems.

Various people wrote papers about

some open issues of security and stuff.

So in 2013 we wrote the first proposal

called next generation Hidden Services,

which basically details various
ways for improving security,

better crypto, blah blah
blah, blah blah blah.

This happened like 2 years ago,
and we still have not been,

we haven’t started heavily
developing, because of the lack of,

basically, developers, since
Hidden Services have been

largely volunteer-driven projects
since like a year ago or so.

So everything was done on
our spare time, basically.

But we’ve been writing proposals,

we’ve been active anyway.

We’re going to start looking over
the various security issues

and the ways to fix them, let’s say.

The first one, we call it
HSDir predictability,

and it touches the subject
that Roger mentioned,

the database in the sky,

which is basically that
when a Hidden Service…

A Hidden Service every time has
6 Hidden Service directories,

6 relays of the network
being responsible for it.

So every day, each Hidden
Service has 6 relays

responsible for it, and it chooses it

using this weird hash formula there.

Which, if you can see, it’s deterministic

so all of them are static,
apart from time-period

which rotates every day.

But the problem is that,
because it’s deterministic,

you can basically plug in
the onion address you want

and the time period in the future

and you can basically predict
the result of that function,

in like, 2 months from now.

So, you can basically know

which relays will be responsible
for a Hidden Service in 2 months

and, if you’re a bad guy, maybe you’ll
go and inject yourself to that place

and you will become the
HSDir of a Hidden Service

and then you can,
like, monitor its activity

or you can do DoS attacks.

So this is not something we like, and

we will attempt to fix it.

Our idea for fixing it is that
we will have to make it,

from deterministic, we will have
to turn it into probabilistic thing,

and we do this by adding
a random value in it.

And this random value is
basically a fresh random value

that the network is going to
be generating every day.

So, how we do this is we use these 9
directory authorities from the network,

they’re these 9 computers, they’re
hardcoded in the source code

and they’re considered semi-trusted.

And basically we wrote the protocol,

that all these 9 directory
authorities do a little dance

and in the end of the day, they have
a fresh random value every day.

It’s not something new, it uses
a commit-and-reveal protocol,

which is some way to do some sort of

distributed random number generation.

And then every day they
make this random value,

they put it in the consensus,

and then Hidden Services
and Hidden Service users

take the random value from the consensus,

plug it into that formula,
and they use it.

And since this is a
supposedly secure protocol,

I shouldn’t be able to predict what the
random value is going to be in 2 months.

Hence, I cannot go and inject myself

in that position in the
database, basically.

And this is the way we fix this problem.

David: Right, continuing now on the
next generation Hidden Services.

The key thing is better crypto.

Right know we have RSA-1024 and SHA-1,

which are considered completely bad to use

and we’re going to use of course

this fancy man there’s work, Daniel.

So it’s basically ED25519
for encrypting and signing

and of course, using SHA-256.

Right now, in TOR, we are experimenting
an implementation upstream of SHA-3.

Although, apparently, we’re not sure
if SHA-256 or SHA-3 will be used, but

right now SHA-256 is a contender
because it goes way faster than SHA-3.

SHA-3 has more things. Still pending.
But, for now, elliptic curves.

So, what to take of that is:
next generation Hidden Services,

which we are actively
working on right now,

will drop all dead crypto.

One of the big changes that’s coming up

is the onion addresses.

On top you have the current onion address

and it’s going to move to 52 characters,

so, basically, your public key.

This is maybe for you
guys considered painful,

and for us it’s extremely painful

to enter this address or just to
type in an address like that,

so, you know, open proposal right now,

or I think there’s an email
thread on our mailing list

on coming up with some more fancy way

to remember an onion address that size.

Like, words, remembering words that just
mash in together and create that address.

So, yeah.

Now, as the Hidden Service evolves,

one of the things we really
want to do is make them faster.

The big difference between
Hidden Services in the network

and a normal TOR circuit
in the network is that

normal TOR circuits usually have 3 hops,

then in Hidden Services you
have 3 hops from the client

and 3 hops from the Service.
Thus you have 6 hops.

So of course much more time
to go through all the relays

than the normal circuit. Now we have
this proposal going on which is

Rendezvous Single Onion Services. And
the point is, you’re gonna do the dance,

the introduction, the rendezvous, and
then once you go to the rendezvous,

instead of the service going 3 hops,
you’re gonna go 1 hop to the service.

So in here we have this artist wanting
to update their Debian machine,

let’s say that, and the Debian
server doesn’t care really much

about anonymity, because we know
where the Debian servers are,

and that’s fine. Thus, clients still
have anonymity with the 3 hops,

then the service doesn’t care, so
only 1 hop. And it goes way faster.

So that’s something we hopefully
will end up deploying soon.

Now, the second one is the Single
Onion Service. It’s roughly the same,

so we have this chef here wanting to go to
his Fairtrade website, you know, whatever,

and the difference here is that
we are going to skip completely

the introduction and rendezvous dance.

And you’re going to do a 3 hop
circuit to a rendezvous point

where the Hidden Service,
let’s say, let’s call it a node,

an introduction point,
which is the yellow line,

and then the client will go
to that introduction point,

and instead of having this current dance

the client extends to the service.

And now we have a 3 hop thing,

no prior work being done
for introduction or rendezvous,

and it goes way faster.

Again, those 2 here and here

are optimization for services
that do not care about anonymity.

And there are plenty of use cases
for that. Facebook, for instance,

or Debian repositories, and so on.

Roger: Am I still on? Great. Facebook
and Debian are really excited about

having one of these options so that
they can have all of their users

reach their service with all the cool
security properties we talked about

but also a lot faster and more scalable

than the current design.

David: Precisely. So, one of the
very cool things we did this summer

was the TOR summer of privacy.
We got some people in,

which we can consider
interns or students whatever,

and one of these projects – that came
out of this cool person that is Donncha –

created OnionBalance. So it’s a way
of load-balancing Hidden Services.

So as you create a Hidden
Service with the top key,

then you copy that key
to multiple machines

so all those servers will
start creating a descriptor.

Basically the descriptor, if you
can remember, is how to reach me.

And we’re going to cherry-pick
introduction points from each

and create a master descriptor
that you can see in that picture;

and that master descriptor
is (?) what clients will use.

Thus you load-balance the network

depending on introduction
points and the instance.

And this is great! And we actually know

that Facebook will actively
start beta-testing this thing

so we can have load-balancing and CDNs

and much more easier for onion addresses.

So, just before I give
these slides to Roger,

the next generation Onion
Services is something

that has been around for 2 years now

and now we’re going to start
working in 2016 actively,

and almost with 4 full-time
developers on that.

It’s still not enough, we need more… we
need resources because we need to get away

from our funding that restricts us
for not working on Onion Services

which we have a bit now.
So resources is very, very important

so we can get this thing
that’s extremely important.

And in the next year, we hope
to get this thing here done.

applause

Roger: Great, so there are a couple
of important takeaways from

what we’ve been describing to you today.

One big one is, there are a lot of

different types of Onion Services out there.

There are a lot more than people think.

Everybody looks at Hidden
Services and says: “Oh,

they’re for websites that the government
hates” or something like that.

But there are examples
like Ricochet, like Facebook,

like GlobaLeaks, like SecureDrop.

All of these different examples are

cool things you can do
with better security properties

for your communication. So it’s not
about hiding where the website is,

it’s about getting more secure ways

of reaching websites and
other services around the world.

So another key point: this is still a
tiny fraction of the overall TOR network.

We have millions of people
using TOR every day,

and something like 5% of the
traffic through the TOR network

is Hidden-Service,
or Onion-Service related.

So it was 3% last year, it’s 5% now,

it’s going up, sounds good,
but it’s still a tiny fraction.

And maybe that’s good, because when
you’re using an Onion Service right now,

you put double load on the TOR network,

because both sides add their own circuit.

Whereas if we switch to some of these
designs that David was talking about,

then it will be much more scalable
and much more efficient

and it would be really cool to
have Amazon, and Facebook,

and Twitter, and Wikipedia, and so on,

all allowing people to get more
security, while using TOR,

while protecting places like Facebook
from learning where they are today.

Another key point, we got all these
cool designs that we touched on briefly,

we’d be happy to tell you
more about them after the talk,

and then the last point: You
run a cool service out there,

please set up an onion version of it,

please set up an onion
address for your cool service,

so that the typical average
onion service in the world

becomes a totally normal
website or other service

that totally ordinary people go to. And
that’s how we will mainstream this thing

and take over the world.

applause

applause

And then, as a final point,

we are in the middle of our
first ever donation campaign.

We are actually trying to grow

a base of people who want to support TOR

in the same way that EFF has done.

So it would be wonderful… I don’t want to
throw away all of our Government funders,

at least not right now, but I
would like to get to the point

where we have other options,
more sustainability,

and we don’t have to look at
each new funding proposal

and wonder if we have to
un-fund people if we don’t get it.

So I’d love to have much more diversity

in the type of people who
are helping TOR to exist

and thrive and help save the world.

So, please consider helping.

applause

Herald: Thanks a lot for this awesome
talk, we have 6 minutes left for questions

and please line up at the microphones

1, 2, 3, 4, 5, and 6 down here.

And while you are doing that,

we would like to hear a
question from the Internet.

Signal Angel: Thank you. I have
a bunch of questions regarding

compromised onion addresses.
Herald: Start with one.

Signal: Do we have a
kind of evil twin problem

and what can I do if my onion
address is compromised?

When there are widespread services

on the TOR net, like Amazon,

how do I know which
one is the official service?

Roger: So the first question, of,

if your onion key gets stolen
or something like that,

that’s the same as the SSL problem.

How do you keep your certificate
for your web server safe?

The answer is: you should keep it safe
just like you keep everything else safe.

And if somebody gets the key for
your onion address, sucks to be you.

Don’t let them do that.
For the second question,

how do you know that a given
onion address is Amazon’s?

That ties into the certificate authority,

the https, the EV cert discussion
that we talked about

where we need to somehow bind
in Amazon’s SSL certificate

the fact that it’s Amazon, and
this is their alternate onion address.

We need to put those
in the same certificate,

so that everybody knows
if you’re getting one

then you know it’s really Amazon.

H: Thank you. I would like to hear
the question from microphone 1

and remember to keep it short and concise.

Q: Again, the addressing issue,

switching from 16 to 52 characters is nice

but if we have to change
the algorithm again

wouldn't it be nice
to have, like, a prefix

to determine the
algorithm for the address?

Roger: Yes, we actually have
a couple of extra bits

in that 52 bytes and we could use them

for versioning or all sorts of things.

And there are some examples
of that in the proposals,

I don’t think we’ve fixed
on any answer yet.

So, we’d love to have your help.

H: Thank you. Please, microphone number 3.

Q: Hey, you gave us a couple of examples

from Facebook, and I was just wondering

if there’s any sort of affiliation between

Facebook and TOR, or Facebook
just happens to be really keen

on offering their services
in less democratic jurisdictions?

Roger: There’s a nice
guy named Alec up here,

who on his own thought of making
Facebook more secure using TOR,

and he went and did it, and then
we realized that he was right,

so we’ve been trying
to help him ever since.

applause

H: Thanks a lot. Microphone number 4.

Q: You said that you want
more and more people

to run Hidden Services.

My question for this is,

are there any guidelines
on how to do that?

Examples of how to do
it with specific services?

Because from what I’ve seen, I tried
doing this for some of the services I run,

that it’s not… it’s painful,
most of the time.

And with the increase of
the addresses right now,

the size of the addresses is going to
become more and more painful. And

one of the things that
I’d love to see for release,

for example, a DNS record
type that’s .onion

that you can add for your
normal DNS record

so people can just look into that and

choose between A, AAA,
and onion to connect to it.

Roger: Yeah. For that last
one, for the DNS side,

if we have DNSSEC, thumbs up.

If we don’t have DNSSEC,
I don’t want to have

that terrible security link
as one of the first steps.

I don’t want to trust
the local DNS resolver

to tell me I can go somewhere else

and then after that, if I get
the right address, I’m safe.

That sounds terrible.

George: So, on how to set up
Hidden Services correctly,

I think Riseup recently published
some sort of guidelines

with various ways you can tweak
it and make it more secure.

I think there are also
some on the TOR Wiki.

But in general you’re right that there are
various ways you can mess up this thing

and it’s not super easy for anyone here

to set up a Hidden Service right now,

and hopefully in the
future we will be able

to have an easier way for people
to set up Hidden Services,

maybe provide a bundle
that you double-click

and it spawns up a
blog, or a Docker image,

I don’t know. It’s still one of the
things we really need to look into.

Roger: It would be really cool to
have a server version of Tails

that has all of this built in
with a, like, Python web server

that’s hard to break into and
automatically configured safely.

That would be something that would
make a lot of people able to do this

more conveniently and not
screw up when they’re doing it.

H: Okay!
applause

So we have a bit of less than 1 minute
left, so I would say “Last question”

and let’s say microphone
number 3 for that.

Q: Hello, I have two small questions.
H: No, one.

Q: One, okay.
laughter

So, I noticed you
have some semi-trusted

assumptions for the random
number generation

for your relays. Did you consider,

or do you think there’s some merit
in using the Bitcoin blockchain

to generate randomness?

George: We considered it. We considered
using the Bitcoin blockchain,

the NIST beacon, all these things, but
there are various engineering issues

like to use the blockchain thing you
need to have 2 verified Merkle trees.

This needs to be coded
on the TOR codebase.

You also depend on Bitcoin, which is
a system quite powerful to be honest,

but you probably don’t want to
depend on outside systems, so…

We really considered it, though.

Q: Thank you.

H: Thanks a lot for this
Q&A, I think you will…

applause

applause

I think you will stick around and be
available for another question-and-answer,

more personal, after the
next upcoming talk, which is

“State of the Onion”, in 15 minutes.

postroll music

Subtitles created by c3subtitles.de
in 2016. Join and help us do more!