[Music]
when i was planning on doing a talk here
i was trying to figure out what kind of
angle to to attack it from
and um normally we talk about these
holistic things with what we are doing
in tor
but i looked at the content that we had
been doing over the the past few years
also with corona and we haven't been out
talking much about what we're doing so
the focus in this presentation is going
to be
uh specifically on the torn network and
the tools that we're using to like
operate and experiment with the network
um
we won't be talking much about like the
anti-censorship technology that we're
also doing the tour browser localization
efforts metrics all these kind of things
so it's going to be a little bit on the
on the back end kind of thing of the of
the network
so my name is alex i've been involved
with the tor project since 2017
and i've been leading the network team
since 19.
we're the team responsible for writing
the software that is called tor like the
binary you get if you apt install tor
and it's also the binary that comes with
tor browser in the bundle
that gives you the connectivity to the
network um i've been doing free software
since 2006 i think the most famous
project i've been involved with other
than tor is the erc irc client
and the om was my first hacker camp in
13 it's really really wonderful to be
back
after we went to om and some of the ccc
camp we decided to do our own hacker
camp in born hack
in denmark called born hack so if you
have the sort of blues when a shower is
over you can pack your car and just
drive to denmark and build it all up
again and we'll do another hacker camp
then
so there was a lot of hands up here when
uh when though you were asked if if you
know tor so i'm going to do like a very
quick primer to to what it is so
everybody is sort of in on the lingo and
so on
we do online anonymity and censorship
resistance technology we do free
software everything we do is free
software because we believe that the
only way to sort of do secure software
with the promises that we want to
guarantee
is to have the source code available for
other people researchers and so on to
look at
the network itself is open there are
many people who are running different
kind of relays how many people in here
are running relays or bridges
okay great that's awesome and we of
course like a large community outside of
sort of the
the nonprofit that we're running
ourselves of like researchers developers
users relay operators all kinds of
people who are participating in one way
or another in our community
so normally when we do software you get
a lot of metrics like we have all these
systems today to collect metrics but
because we're doing anonymity we have a
hard time sort of figuring out how many
people are actually using it but the
current research seems to indicate that
it's somewhere between 2 million and 8
million daily users
so if we take a quick primer to how tour
works so here we have alice we have bob
bob is usually a server that you want to
reach on the internet we have the tor
network in the middle consisting of a
number of relays operated by by
different kind of people so what alice
does is that she knows the entire
composition of the network she knows of
all the relays that exist in this system
and decides on three nodes that she
wants to connect through before reaching
bob she starts by establishing a session
key like a cryptographic session key
with the first relay she expands it to
the second relay
further expands it to the last relay and
then finally makes sort of the tcp
stream out to bob and is able to start
communicating over like application
level protocols such as http or https
and so on
we call this sort of a telescope style
connectivity as you can see it sort of
resembles some of the flagpoles that we
have here in camp and that fits pretty
well to that
usually when we talk about this
these three nodes with the first one we
call a guard node the second one we call
a middle node and the third one is the
exit node we also have something called
onion services basically if you want to
think of onion services you eliminate
the exit node add another node there and
then you mirror the entire display on
the other side because onion services
are sort of these services that exist
only in the tor network itself
so a little while ago our wonderful ux
and ui people were
were asking this survey out in the tour
community on
what kind of problem people were facing
with using torn the daily and
this was sort of the order that things
came up with um in in terms of what was
more important to the to the general
user
the speed problem is of course related
to the performance of the tor network
there's a lot of people who have sort of
a feeling that tour is slow to use and
they would like to be have to be faster
and it of course also has to do with
like the throughput and the latency is
related to that blocking has to do with
website blocking we see a lot of capture
portals when you're using the tor
browser from websites who sort of deny
access to tor browser users
the blocking issue is particularly going
to be interesting in the near future
because the big fruit company have
announced for their paid customers that
they have like this privacy relay on
their iphone devices and so on so
they're probably going to be facing some
of these similar issues that we have or
the internet will have to evolve to to
use smarter technology than just
blocking people who
seems like they're doing something bad
we of course have some privacy anonymity
guarantees provided by tor that
that we have to
considerably
like over time tune we have the security
of all the different torque components
we have um of course sort of the user
interface of our products which has uh
if you're using it on the daily you will
probably have seen that it has changed a
lot over time and is i personally think
it's getting way better
if we look at
the toy network it's an open network it
means that everybody can join it
everybody is able to run a relay if you
have an ip and you have some bandwidth
you're able to set up a node
we right now have between six thousand
and seven thousand relay notes and
like i mentioned earlier it's hosted by
probably by some people in here and by
different uh non-profit organizations
around uh around the planet or just
individuals who set up a machine at home
because they have some spare capacity
we have in the network nine what we call
directory authorities these are
specifically trusted nodes they are a
little bit like a ca in like the x 509
tls system and we also have something
called the bridge authority which is for
these
non-public bridge nodes that
that also exist for people in censored
areas who are connecting into the
network
if we take a look at the number of
relays over time we can see that
specifically after the snowden
revelations in the summer of 2013 we
sort of see the curve going up and then
it's sort of reaching a plateau where we
are today
[Music]
the
the bridges are a little bit more sort
of laggy but we recently ran a campaign
to get more bridges unfortunately a lot
of people here in 2022
have started running bridges
even though we sort of have hit sort of
a sweet spot between somewhere between
6000 and 7000 the bandwidth of the
network continues to sort of grow
and get faster also as the internet in
general gets faster
we're going to look more on the
bandwidth in in recent time later in the
presentation but i'm quickly going to go
to uh to sort of the next part
so one of the small thing that we are
about to come up with here in in the
near future
the um the idea with many of these
things is it's stuff that we are either
already working on or something that we
have grant uh grants out to to receive
funding for
so that we are actually able to do it
so people who are familiar with some of
the technical aspects of the tor
protocol we use something called
circuits which is the internal layer of
encryption where you pass what is called
cells around this is similar to other
protocols that uses packets or another
synonym for that
we pass around like these 498 byte cells
one of the issues we've had is that we
don't have we have signal signaling
mechanisms inside the protocol where we
are interested in transferring data that
is smaller than like significantly
smaller than 498 bytes
um we have two proposals there that we
have merged into this what is called
proposal 340
which is our way of sort of like doing
rfc style network updates that are that
are being reviewed
one of them is packed cells it allows us
to take multiple smaller cells and
compress into a single cell that will
then be expanded on the receiving side
whether it's the guard middle or exit
node that is the target
we also have something called fragmented
cells which is i'm going to return to
why this one is important in a bit
but it will allow us to have
very large cells that we split into
multiple cells and will then be gathered
at the destination
and will be packed back into into the
full payload
so the reason that we need this is
there there's a lot of um i don't know
if people are like following these in
this competition that has been recently
on post quantum cryptography
um there was i think it was announced
two weeks ago who the winners were
but these post quantum handshakes we
have historically moved from like uh rsa
and classic divi hellman over to
elliptic curve cryptography when we
entered sort of the mobile world
and um
we got significantly smaller handshakes
like there was way less data on the wire
that we were transferring around but now
we are entering into this
reality of this post quantum
cryptography and the idea there is that
you take these
new handshakes that have significantly
large
both secret keys and public keys but
also the handshake material that you
have to transfer around is
large and biased it's also larger than
what we use for rsa
and this is why we need the fragmented
cells to carry over these
this amount of additional data um
we have two parts that we need to
protect for people who are not aware of
sort of the post quantum stuff the idea
here is that we're worried that
eventually someone will build a quantum
computer and be able to decrypt um the
the handshakes that we've been
transferring over the internet added
with that if you have this notion that
there might be an adversary right now
recording all internet traffic even the
encrypted one then they will eventually
when these machines become available if
they become available we'll go back and
like replay all of this and like decrypt
every
transmission that has happened in the
past right
so we have two parts of tor that we need
to look into and secure against this
kind of adversarial model the tls layer
is sort of the outer layer of the tor
protocol we use ordinary tls we don't
use like let's encrypt or anything like
that because we don't depend on external
services the network is sort of
self-hosting so to say
the tls layer protects against the
adversary who's recording traffic going
around in the network right
and then we have the tor circuit layer
which is a protection mechanism against
an adversary who is currently in the
network for example as a middle node and
is monitoring the encrypted traffic that
it sees that is unpacked from the tls
stack
one of the the other things that we
recently deployed in the tor 047 like
the the post quantum stuff is not
deployed yet that's still in sort of the
research phase
but congestion control was added here
into tor 047 which was released at the
end of april into its stable version
there was some alpha releases before
that
what we did there was um
i personally find it to be a very
interesting project it was led by uh
tour developer mike perry and we use
pretty much all of our different teams
and like all the researchers that we are
near contact with to do this
so what happened was that we implemented
three algorithms like classic algorithms
from tcp for congestion control
it's westwood the one called vegas and
the one called nola you can google these
things and you will be able to read
wikipedia articles about how it works
and
what the team did then was that they
took this very scientific approach to it
with running a ton of simulations to see
how the performance were actually were
they working or were they not working
we um we also we we found some issues
with with two of them despite having
spent time implementing them namely uh
westwood and nola
have this um
compression problem that is uh that is
happening in some congestion algorithms
in the way we were using them so they
overestimated this bandwidth delay
product which led to like these bizarre
conditions that that didn't really work
uh google also came with a bbr algorithm
which is which is another sort of
schoolbook uh congestion control
algorithm um but it would suffer from
these same kind of mechanisms that we
saw with the westwood and nola so there
was no reason to to further dive into
this
um
however
the vegas one
worked extremely beautifully and worked
in simulation uh exactly how we
were going to think of it in the paper
so these plots are a little bit hard to
read it's sort of a distribution of um
of the data that we're sending the blue
you see um is the uh
is the old version of tor and the
rng yellow thing is
the modern version after congestion
control
the first one is simulated as being a
client in
germany where we have because in germany
there's hetzner and like we generally
have a lot of tour notes in central
europe and in northern america
and the second
image is from hong kong
and what we see here is that in general
people are able to achieve much higher
amount of bandwidth
when doing this
it's worth adding that historically like
the team that i'm in we have when we do
experiments we have like these two tools
that we can pull in for doing local tour
network simulations we have one called
chutney
which is a tool where you specify in
these python files that i want a toy
network consisting of 200 nodes some
bridges like four directory authorities
and then it spawns it up on your machine
and you can do like some some like
testing to see how things are working we
also have sort of the big artillery
which is called shadow it's made by
originally made by
a person called robinson who's one of
the researchers heavily involved with
tor
and he has actually a team now who's
sitting and working on getting a shadow
to
work a lot better and we finally started
adopting this in our workflows
i i don't know if there's anything out
yet um on our blog like
blockchairproject.org but it's really
interesting to look at how this was run
we we did it with it's almost worth its
own talk
um
we use gitlab runners to spawn large
amounts of simulation nodes so that the
team could
consistently every time they wanted to
run new experiments it was just pushing
and then they got the results and they
could sort of see it a little while
after
so this is um
the total relay bandwidth plot that you
saw before where it was like going steep
up and it was difficult to see this is
only from 2021 and 2022.
um let's see if this thing works
okay so you see these two huge spikes
here to understand this plot
the top one
the the top part of the plot
is relays are consistently observing how
much traffic they're seeing and they're
noting down the maximum value of traffic
they're seeing in the network right now
and they're reporting it back to the
directory authorities when they sort of
call in and say hey i'm still alive
the
orange
part is
where they write how much real traffic
they've actually seen
so these two spikes that happened in
oh wow it's very dead
these two spikes here are
comes from an experiment where what we
did was that we essentially wrote a
script that would iterate over the
entire set of chore notes
and start just hammering traffic over it
in a very short amount of time so that
the relay would discover its actual
capacity
and be able to report back oh i actually
am able to transfer much more traffic
the rolling window then goes out
eventually and we fall back to sort of
the the
normal kind of of traffic that's
happening
and as you can see the um
the amount of reported traffic is not
increasing so this had no impact on sort
of the the bandwidth of the network
what is however interesting is
here this is the moment where we
deployed congestion control and you can
see that we sort of start increasing the
amount of of traffic that is in the
network
um but we also start seeing the moment a
little bit after the tor browser release
came out with 047 in with the stable
version and we can see people start to
utilize
more traffic
however as you can see the curve is sort
of cutting a little bit short after
we have this um
since we are a little bit of a social
experiment as well with that we have all
these people running the relays
we unfortunately also have some people
who are attacking the network using sort
of traditional mechanisms of denial of
service through either flooding or
finding different kind of things in the
network that is that is costly
so in the last couple of weeks we've
seen
like an ongoing denial of service using
different kind of techniques
and
it has made it pretty hard for us to to
see if the deployment of this congestion
control feature is going well but
usually after a while these things stop
and we also have some some plans for
um mitigating some of this that i will
return to a little bit later in the talk
this is a very beautiful
plot
it shows the number of like the versions
that are currently active in the tor
network
two versions that are a little bit
special the o45 is an lts version i
believe that is the one packed in debian
stable today
and o35 was the older lts version which
is now like completely gone
um
it's really really awesome like i said
the we released
0.47 staple at the end of
april
and we can see very quickly thereafter
that relay operator starts um upgrading
from 046 to 2047
so a massive thank you for to the people
who have been doing this if you're
running relays and you're not upgraded
to 0.47 yet please when it's not as warm
as it is now
go home and and and upgrade because one
of the problems for us with having this
very heterogeneous network
is that
we we need to be able to upgrade quickly
to get the new features so we can
actually see that they're working if
nobody is upgrading then we will
finish and wrapping up our part of it
then we'll deploy it to the network and
there will be all kinds of problems
so we've spent like significant portions
of time doing like reach out and trying
to get people to um to to actually
operate so so thank you to everybody who
has been doing that and and continue to
maintain their tour relays in in a
really nice way manner
we have some more stuff to do here in
the congestion control for people who
are a little bit technical about the
tour network we have something called
flags that the directory authorities can
give to to relays we have something
called fast and we have something called
guard
fast is that you are like a part of the
faster amount of relays that we're
seeing in the total network and guard is
that you seem to be stable enough that
we can use you as the first node
we have these cutoff values which says
that you can only get this flag if you
transmit like if you're able to transmit
a certain amount of traffic
and we are likely going to bump that
value up because we still have a lot of
um i guess it's hard for us to to guess
but i would assume it's something like
people are running tor relays on their
home connection on our raspberry pi 1
and is probably suffering a bit so such
notes shouldn't should likely not be
neither a fast nor a guard because
if it is the guard node it will
significantly impact
um people who
who want to have a faster experience
over the tor network
so to wrap things up a bit if you're an
onion service operator you will also
benefit from the congestion control
changes relay operators should probably
prepare if they're running big relays to
set limits to
to to how much bandwidth you want to use
because as the network upgrades slowly
we will see the hoses hopefully get get
filled more
if you want to read more about the
congestion control stuff you should read
mike perry's summary block which is on
on this link i will also upload this
slide somewhere where you can just click
on it if you can't remember it but it's
one of our recent blog posts
another thing we're going to look at is
something called conflux
um the idea here is to add one more
layer to tor which
should ideally work like help us with
some of the network performance issues
or bottlenecks
and that is called a technique called
traffic splitting
we have a proposal for it and we have
like the paper originally written by the
by the researchers who did this um and
it is worth a read if you're interested
in that kind of stuff
the way it works is that normally we
have this alice and bob image again
where alice have established a session
all the way out to bob
um
one of the issues here is if like we
know the network like the internet is a
pretty chaotic place um so the
so we're traveling through a lot of as
numbers in in this plot like it's not
like these nodes are sitting on the same
network or anything like that
um so if one of the nodes or the network
between them goes down the entire
circuit is turned off and you lose like
your ssh connection or your download
stops and these kind of things
so what conflux does
is that it allows alice to establish
multiple paths to the exit node and be
able to transmit on the one that is the
least congested so we use the congestion
algorithm to sort of get a feedback on
how things are going and we will use the
fastest one if a connection is torn down
we can just start transmitting on the
other one and start establishing a new
conflux path through the network at the
exit node and
the exit node will then be responsible
for buffering a little bit and
transmitting data of course in the right
order
oh the next slide is a hot potato
so one of the issues we've seen with the
denial of service attacks is that
they are often happening towards onion
services
and because we have this
architecture today that you have
the tor client running and i say client
because onion services are essentially
clients to the network
and then you have nginx or a web server
or an irc server an ssh server or
whatever running on it
there's no good sort of pushback
mechanism that we know from distributed
systems here to sort of
avoid having to flood the tor binaries
added with the tor
the the current architecture of tor is
single threaded and like not very good
at handling these many connections we do
see attacks on onion services that are
problematic
so one of the designs that we can
implement here that
it's disabled by default
but the idea is that if an onion service
starts detecting that it's being the
target of something
that
is sort of pathological in nature what
we can do is that we can start setting a
difficulty at the introduction points
into the network into the onion services
where the client have to deliver some
kind of proof that they've done a
computation so you cannot do the trivial
flooding here
we've gotten some help for from
a hacker called tivador on this and
we're still experimenting a little bit
with the entire setup
it all happened during a heck week doing
the ongoing donatio service a couple of
weeks ago with
where david and mike dived into this
so i mentioned a little bit some of the
shortcomings with the
with the tor architecture itself and
sort of the
performance nature of it
one of the really cool things we're
doing right now is a project called rd
rd stands for a rust tor implementation
so
what we're doing is that we're
essentially rewriting tor and rust in a
smarter way
and the goal here is to build it as a
library to work with tor in general
so with tour as it is today it's it's
like this very classic
unix architecture where you have like a
single binary it does multiple things
it's both a client it can act like a
relay it can act like a directory
authority that there's only 10 off and
like running
in production right
it's also an onion service client and
all these different kind of things so
instead of doing it with this one binary
and architected as a
as a binary with a ton of global state
and so on what we're doing is that we're
building it as a library as a rust
library
this will hopefully make it easier for
example mobile developers to integrate
tor into their applications for example
for people doing messaging or people
doing we've had these uh kovit 19
tracing project in germany who's been
experimenting a bit with integrating rd
on on ios
historically we've also used a library
called stem which is a python library
which can parse like the directory
documents that we are passing around and
the different objects that exist within
the tor network
and the goal here is that we get rd to
also do this so we
so our metrics team eventually will be
able to parse like network descriptors
in rust and and use that instead
onion services is of course also a big
part of it onion services today is a
binary where you just get like tcp
connections coming out of the tour
process into your service or unix domain
circuits
and having onion services being able to
not be
having any sockets involved in all that
it's just like api calls where you can
for example do a callback instead it's
going to be
way way way nicer for um
for developers because we will also be
able to deliver more metadata about
what's going on in the network
um even though we have tried some of
those things with tor that that was not
very beautiful we've done some pretty
iggy hacks for
for the large providers of onion
services like facebook and cloudflare
and so on who needed this
so why on earth would we start rewriting
a project that have existed for so long
and it's such a
a big part of the code base that we're
running
so writing safe c and i have safe c and
quotation marks it's pretty costly like
we spend a lot of time on like static
code analysis having external parties
review stuff
even doing internal code review in the
team is costly
we have to
be very careful when we architect new
plans that we
are able to split it up into sort of
smaller chunks so we won't have half of
the team spending two weeks sitting and
reviewing code
so added with that the network team at
tour was all very excited about rust and
all of them expressed interest in
spending more time of it so it grew a
little bit natural we did an experiment
before rd with
replacing parts of the c tour code base
with rust
but all the because of the tour
architecture the all the different
layers where we had to call from sea
into rust and from rust out to sea
became pretty nasty um
and uh we never decided to to sort of
instead do it the the hard way and do it
from from scratch
added with um people in here are
probably familiar with cvs
we have our own tracking called a trove
which is when we have
like security implicating bugs we tried
to track those specifically and we could
look at uh thanks to nick matthewson who
spent some time categorizing our
different bugs that we've used this
trophy it turned out that 21 out of 34
of these was related to memory issues
that like the c programming uh allowed
us to do
um and
like i'm not a very uh bragging person
but i think the team is is a very good
team of c programmers
and we even make these mistakes and i
think that will go for every like good
team who is who's writing large code
bases in c
so the audio roadmap as it is right now
is that we're
we're working towards api stability so
that we have some kind of base where we
can start telling people like try this
out and start experimenting with stuff
um we need to at some point focus on
like usability performance and stability
so that things are working things are
able to reach the network every time and
the way you sort of expect it
for the 1.1 release we are going to
start integrating pluggable transports
bridge support being able to run these
things there's likely some stuff with
plugable transports that we want to look
at with sort of the general architecture
of that
1.2 is going to be onion services and
2.0 is going to be the release where we
should be able to replace tor as a
client not as a relay node but as a
client
we will after that begin working on
relays bridges directory authorities and
all these different services that we use
in the network
relays are going to be really
interesting because of the the
architecture of rd we will naturally get
sort of a multi-threaded architecture
and hopefully we will see some
performance gains and notes because of
that so people will
avoid having to run multiple tour demons
on their
on their machines
this of course have some implications
for the what we can now call a legacy
tour like the currently existing tour
right now we have three out of seven of
her team members is working full time on
the rus and
and rd related deliverables um our goal
is to get the entire team over but we of
course still have like deliverables we
need to do and we also have to continue
to support ctor for
because it is the one that we ship in
tor browse that is the one that's
currently running the network right so
we will not be able to just completely
abandon the ship and and go do this
other thing we're going to continue
maintaining both in parallel for a
little while but you will likely see a
reduction in um
in features that are going in
with the exception of stuff that of
course touches the network where we need
it for for some of the other things like
post-quantum cryptography and these kind
of things
one of the other exciting things that we
are planning to do is udp support um we
want to support these sort of more
modern technologies such as uh like voip
and webrtc we haven't there touching
into that so far because like the the
latency issue has been too hard like we
need to solve performance before we need
to go to this thing
um
the cool thing about that is with like
with congestion control we are able to
do this
with only having to upgrade clients and
the exit nodes like the middle nodes and
the other parts don't have to upgrade so
uh one thing i missed to say when i said
that it was very nice all the operators
upgraded was that we actually saw a much
higher amount of people upgrading
quickly who was exit node operators and
that means that the congestion control
part was available for the clients who
had it earlier
we will use the congestion control
system to decide which packets to drop
as you know with udp
the the way most of the protocols is
engineered is that you both have to take
into account the mtu of the networks
that you're traveling in but you also
need to be aware that routers on your
path might decide to drop an individual
package if they are congested or
whatever
the way we are going to do it is
historically we have been talking about
doing this inter-relay communication
over udp that is completely dropped with
the congestion control stuff we're going
to continue being a
tcp over tls with tcp
the way it works is that you will
establish a normal tcp connection
through your like guard and so on to the
exit node and then instead of creating a
tcp stream you have the option of doing
a udp connection out from the exit node
this will um
this there's not any good options sort
of um socks or these kind of things for
udp even though
it is specified by itf and so on that
there is an option for it but most udp
applications don't support it
because of that we're going to start
looking into
having a vpn mode for tor
as you know guardian project who does
orbot on android already have this it
only supports tcp and it's sort of
limited by the functionality that exists
in tor we're going to build from scratch
with rd um
like an application which is essentially
a vpn
the goal is to release at some point in
2023 i would guess it's going to be in
the late part of 2023 but i don't
remember the the deliverable dates
exactly
to do this we're doing a
small component called onion mask the
way it essentially works is that you
should see it as a net router the way
most net routers works for udp is that
they need to sort of see a udp package
stream as sort of being a little bit
stateful despite that we teach people
that udp is stateless
so what this library will be doing is
that
it will read and write ip packets from
these 10 devices that exist on the
platform
it will be handling multiplexing
incoming tcp and udp flows to rd's
circuit interface and sort of making
sure that things get transported
we we will do onion services a bit like
the dns port works if you're like a cube
user or something like that the way
you use tor there is that you have a
fake dns server which gives you like a
token
um when you try to connect to a dot
onion and uh
that token can be like and a
specifically ipv4 network or a larger
ipv6 network and then when it sees
connection going to one of those
magically mapped ip addresses it will
accept your connection to the onion
service instead
we also need to do some basic filtering
um like that i don't want applications
to this endpoint or i don't want
applications from this this source point
usually when you use netstat and stuff
like that you're used to looking at
these five tuples like you have the
source address source port target port
and target address and of course the
protocol whether it's tcp or udp we need
to populate a little bit more metadata
to be able to do isolation primitives
properly as you know in tor browser we
isolate like tabs and like the origin of
the website so that they cannot sort of
see that they're coming from the same
what we have identified that we is
hopefully able to do on modern android
is that we can get the application uuid
um a hostname that is the target and
also the dns cookie that is that is
available here
so we're getting towards the end
if you want to help the tour project in
any way you can run tor relays or
bridges you can teach others about tor
and like these things that excite you
about privacy
finding and fixing bugs for us is really
nice there are some features that we
or or
minor annoyances
that we don't have time to do because we
also have all the like research
deliverables and grants and so on that
we need to do
so we love getting help from volunteers
and with rd it seems like the volunteers
it's gonna be it's getting easier to to
contribute to these parts with uh
when we sort of leave the dc code a
little bit behind
you can of course also donate to our
project at the end of the years we
usually have these things where you can
donate and get a t-shirt and so on
for the relay operators in the room
we have a meet-up tonight in the sea
base tent
it's at 21 and we'll meet and talk a bit
about what's going on and people can ask
questions and like we can have a bit of
a chat about
what's going on in the relay operators
community
that was all for me i have
some times for questions i believe um
[Applause]
uh now you can
thank you very much for the talk it was
very interesting also for me personally
i think
for most of the people in the room uh
too since uh
barely none left
so
now i see we are queuing up uh
let's start with uh
the mic at the front please
hi i wonder are you using or are you
planning to use quick for transporting
data uh
in future
uh you're thinking about the inter relay
communication yes so quick was when we
when we started the congestion control
project quick was considered because
quick comes with the dome mechanism for
both defining the cryptography like
roaming and the congestion control it
was evaluated but we
it would it was a significant easier way
for us to upgrade just the congestion
control at the end point over tcp
because most of the network is connected
on like good lines on like the internet
lag in data centers and so on so quick
was evaluated but we decided not to go
with it there is a research group in
cambridge before quick was the thing
that did a tour version where it does um
dtls over udp between the inter
communication there between relays and
we looked at it and it seemed more
natural to upgrade tcp because
we are very familiar with tcp sort of in
general right thanks no problem
um okay thank you for your question then
we go to the back microphone
hi
thank you for a very nice talk
um some context four years ago around
four years ago there was a certain
middle eastern country that
was trying to block telegram
huh i can almost not hear you
can you hear me now yes yeah
speak up a bit yes it's fine okay so
four years ago there was a certain
middle eastern country that was in the
middle of an upheaval and they tried to
block
telegram access
for people to prevent them to organize
from organizing and as a result sciphone
had a huge uptick in bandwidth and as a
result to that they started blocking the
providers
of iphone
aws ip blocks etc
the graph that you showed
that showed an uptick of bandwidth
kind of correlates to a certain big
event which is which started
recently
yes that one yes
so if i'm i'm i'm not really seeing the
months there but we are in 2022 another
that one the at the end right
yeah 20 this is uh at the where we are
now the very end
uh okay but if i'm looking that
correctly the big uptick started
somewhere around
april march april yes
um okay i see some correlation with the
current events which are happening on
european soil and another large country
which is trying to again block its
people from getting access to uh well
organizing power and and information so
there's i see some correlation but is
there actually any causation have you
investigated and also the the ddos
attacks that you mentioned could that be
also in response to people maybe trying
to use store
i think if there was a correlation then
either our congestion control stuff
doesn't work which i i would be uh very
sad about but the interesting plot is
more this one because that is what the
traffic has that has actually been
utilized this is just what we observe
that is available in the network so this
bumper and the utilization fits
extremely well with the tor browser
release and the availability of
congestion control so i don't think
those two things are related if i had
i
usually also have a plot in my slides
that describes
traffic coming in for bridges we would
be able to there see
the
the sort of the guip of the incoming
clients batched up in these small
buckets
um i think if you go to metrics to our
project.org you will be able to see it
more specifically to the country and
then i think you would be able to make
probably a better conclusion than based
on looking at the global state here in
the network yes excellent i was trying
to detract from the program no no no no
that's fine excellent thank you it's a
good question um okay let's go to the
front mic thank you
hi there thanks uh for the talk it's uh
quite good and thanks for your work it's
uh it's very important um i do have a
question about trade-offs because you
did have your uh your survey there you
had the slide it said
we think speed is more important than
privacy
and then two sl two slides later you had
the thing about quantum handshakes which
of course are larger and uh that means
that will decrease speed so there are
some trade-offs you have to make there i
assume so how is that uh decision how is
that made
so of course um
this is not the kind of survey where the
end result is that we uh drop everything
we have in our hands and then only focus
on speed and then like the privacy
like that that would not be the thing
right um
so the the thing with the handshakes
remember that the handshakes
you you establish a circuit to the exit
node there you have the number of
handshakes but from the exit node you
can create multiple streams out from
there so the cost of these additional
handshakes both in terms of computation
power but also in transport is is not
that important in this it's actually
it until we also started having it in
tls which is likely going to happen very
soon like both google and cloudflare
have done experiments with that um
this cost is very minimal to the entire
part of the network but you are right
everything we do has to sort of balance
like are we doing something that
potentially has performance impact the
proof of work stuff historically on
apple ios platform we've been suffering
because network extension has a
ridiculously low memory limit
far smaller than what we were able to do
they recently bumped it in like version
15 or whatever it is
and there we sort of need to be sure
like can we even do like a like a memory
ballooning kind of proof of work there
because if we just have a network
extension and we run out of memory then
torque closes and everything just flows
over to the internet right so yes there
is a lot of sort of analysis being done
to what are the impacts
of the features that we're doing
thanks for the question and now we go
back again to the back mike
thank you for the talk
um i had a question about the conflux
the multipath uh
feature
and i was wondering if it had any
security implications for kind of
correlation timing attacks absolutely
and like everything we modify and these
kind of things needs to have pretty deep
analysis done to them on sort of
correlation factors and there's also
like all these papers about
choosing the guards and we have like
this new system called vanguards that
also implies implic is implicated here
um
the paper
that
that you can read here the path less
traveled overcoming towards bottlenecks
with traffic splitting has some of that
analysis and we're probably going to
discover more things as we as we
engineered so absolutely every time we
modify anything on anything related to
incoming flows and outgoing flows it has
to have some pretty deep analysis done
to it
thank you
thanks for your question and now
to the question in the front mic
thanks alexander great talk
i couldn't really follow the udp part
you said you had a
trick that
you had a dns cookie that you use is
that just purely for the exit relay in
order to track udp connections
no
the dns cookie is for onion services
only
it's only used for onion services
because onion services are a host name
but like when we're working on layer 3
we need to have ip addresses so the idea
there is the dns server will respond
with like some fake long ipv6 address
then when you make a connection into the
software net router onion mask then it
will be able to look up and say hey it's
a connection to this onion addresses
establish a torch circuit to that
instead and you don't need it for tcp
right
yes we need it for tcp
as well for onion addresses because you
also and tcp is also on ip level
the
the udp part the reason that we need a
vpn for for the udp but the trick there
is
is that we don't have any applications
don't support any protocol that allow us
to proxy udp traffic
despite like i think sucks five has a
way to both do sort of service endpoints
and uh just like connectivity outwards
over udp but like none of the
applications seems to be using it okay
thank you no problem
and uh
back to the back mic
it's not on like on
now so the current version of taurus is
0.4.7
been wondering why it's not a one dot
etc version is there a specific reason
for that
there's so many free software projects
you could ask that question um
no no there's not um
like um
i i'm personally a big fan of these
identifiers where you use like a year
and a name but uh like my team is
probably if they're watching this will
probably say no we're never gonna do
that um we've just sort of continued
doing it we don't i don't even think we
bump it i think we went from 0.35 to oh
for
zero um so so there's not a great system
it's just like hey now we've done like
some nice features let's bump the
the middle identifier up um so now we
with rd we are probably going to quickly
try to get up to 1.0 and then start
doing like more aggressively in the in
the modern uh versioning scheme of
software
okay thanks no problem
um okay then one question from the front
mic and
uh
we have nothing from the internet if i
see correctly
and this would be the last question for
now
hi
i'm very excited about the rust
implementation
but i'm also a little bit worried about
putting all development effort this
early on to this specific implementation
because there is precedence of other
projects which just have a very well
maintained code base and they just want
to throw it all over and try to build
something new and then years later they
are still working on the old code base
and the new one didn't really catch on
it's a cost benefit right you need to
sit down and look at what are the risks
of doing this um
will we be able to in 10 years be able
as an ngo that is not paying sort of the
same kind of salaries that that like
these software engineering companies are
doing
will we be able to hire really good c
programmers that gives the guarantees
that we want to provide like will the
will the young and upcoming hackers will
they be sitting and reading knr books
about c or will they be doing rust or
python or haskell or something else so
there is a little bit of
a modernization
thought to it as well added with that
the team also had an interest with doing
that
i had a talk at shah where i was talking
about my pet project which was a tour
implementation in erlang um and i like
i've completely abandoned that because
now i'm spending all my time on on sea
tour right and and our new rust efforts
so yes there is absolutely a risk to
that um
we we hope we won't fail
that is uh that is the thing
and um
but there's a lot of momentum in the
in the organization and also from the
partners that we have
with solving some of these very holistic
issues with like tours not a library
right now is a freaking nightmare to
integrate into anything
and we hope that
we already see that people want to test
stuff even though we are not feeling
like ready you shouldn't be using this
yet um so we hope that will uh that we
will also be able to get some help also
from the greater communities
thank you
um yeah with that um i would kindly ask
you to give it up for alex
and
you