Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/476 Thanks!
So this talk is about
a recent development of the Great
Firewall of China and its joint
work between a bunch of people,
most notably Roya and David,
who are both brilliant researchers
working on fighting the good fight.
And coming up with techniques to
circumvent Internet censorship and
unfortunately cannot be here today.
They didn't make it to Hamburg.
So on the back up plan.
So I'm the one presenting our work
and I hope I'm going to do them justice.
And what I'm talking about, the Great
Firewall, then
I'm talking about the Great Firewall of
China and academia
has spent a lot of time
researching this system over
the last couple of years.
So I'm maintaining an online bibliography
where you can find a bunch of papers
dating back many years.
And at this point, we have a pretty good
understanding of many aspects
of the system.
So we know, for example, what it blocks.
We have lists of keywords, we
have lists of domains,
we have lists of you or else that are all
blocked when you're trying to access
the Internet and you are in China.
And we also have an understanding of how
this thing works.
We know what it does.
For example, in checked TCP
research segments, try to slipstream
to terminate network connections
and the same for DNS.
And it's a little bit
more challenging. But we also have some
idea of where the system is in
the network. Right.
Since there was some back and forth over
a couple of years where we weren't
completely sure if it's decentralized
over all the provinces in China
or if it's the central system in the
backbone of the network.
But over the last couple of years, we've
got a better understanding of this and
we're doing pretty good.
A big issue is still that
it's difficult for us to come up with
continuous measurements.
Right. All these studies and ours is no
exception are one off measurements.
We do it once we get the data, we publish
it. But it could change tomorrow
and nobody might notice.
And my coauthor, Saroya, for example,
is working on changing that by
proposing systems that can continuously
measure censorship over time.
And before I start with the meat, I want
to give you a quick overview
of the most common types
of censorship in China.
A lot of domains are blocked, right?
So this is off the shelf.
DNS poisoning there is really not
that much special about it.
You mentioned a user is sitting in China
trying to connect to a Web server
outside the country.
And what happens is your traffic
is basically subject to deep packet
inspection.
So this shady person here
represents a deep packet inspection
device.
It looks at your traffic
and if it finds patterns that match
sensor traffic, then what you get
is a bogus response,
basically. Right.
And I didn't make this IP address up, so
this is actually what I got when I was
trying to resolve Facebook dotcom
in China and
for some reason it's an IP address in the
United States. Right.
It doesn't make any sense.
And it's well known that the firewall
uses a set of approximately 10
IP addresses. It likes to return
to basically misdirect users.
We are not completely sure why, but for
some reason, this is the kind of DNS
poisoning they're doing.
And interestingly, as
a client, if you wait long enough,
so just a bunch of milliseconds, you also
get the original response from the DNS
server Red,
which is funny, because if you're sitting
there in China and you're trying to
resolve a blocked domain, you actually
get two responses.
So this is basically a race condition,
right?
The firewall is trying to give you
the sensate domain faster
than the real genuine Web server
DNS resolver.
And this works pretty well
for the firewall. Not always.
Sometimes the original response
is faster and reaches the client faster
than it doesn't work.
But you basically get two responses and
the first phone basically wins.
But like I said, there isn't much special
to this and there is also a keyword
blocking. Right. So if you have
blocked keywords in your DNS requests,
same story, a deep, deep
packet inspection device looks
at your
get requests and
sends you a Tsipi Reset segment.
And it's the exact same story.
Right.
It's a race condition.
They're just trying to send this reset
segment to your browser before the actual
webpage.
And you might think https fixes that
for everyone. And that's kind of true,
but it doesn't help you that much since
you still rely on DNS.
Right. So the DNS censorship
is really the most effective
system there. Right.
Since it just precedes HTP.
It doesn't help you that much without
DNS.
And to work around
that, the basic idea is to just
take your network traffic and wrap
it in some form
of cover protocol, something
that tunnels your traffic
and gives you maybe even security.
Right. Some fancy properties
like authenticity and confidentiality.
And there are a lot of tools for that.
Right, that basically
try to wrap the traffic for you.
So it's harder for deep packet
inspection boxes to to filter stuff.
And this is really a problem for the
firewall. Right. Since
traffic that is encrypted is difficult
to parse.
And at this point, deep
packet inspection boxes might be left
guessing what is in there, what is in
this encrypted connection?
Is it H2 Depass or perhaps
a VPN or TOR?
And it's not entirely impossible
to to learn these things since
you can look at a bunch of things.
Right. The most obvious one being port
numbers. If it's port four for three,
it's probably HSDPA.
If it's nine and three, it might be IMAP
s right.
And you can also look at the type
of encryption.
A lot of protocols use tools.
Right. But there are other protocols out
there, such as s age that use
their own crypto that do not rely on
tools.
But if you look only at the protocols
that use tools, then you can
still look at the specific
set up of tools.
Right. Since a lot of protocols use
tools differently, they configure it
differently.
And it's possible for sensors to look
very closely, very carefully and
identify these differences, which
can then be used for a blocking decision.
And if all else fails, then you can still
look at flow information, right, there
are packet lengths that leak information,
there are timings, there are the
direction of packets,
and all these things can be used.
Right. But.
All it gives you is basically you
can make an educated guess, right?
Often there is just not information in
there to really know that this is
something you want to block.
Right. So there is some uncertainty
left and this is poison for sensors.
Right. Since uncertainty leads to
collateral damage, meaning that they end
up blocking more than they really want
to block.
And who remembers this in this
incident from a couple of years back when
the Great Firewall was messing with
traffic to get up
and over a couple
of days to gradually increase the
censorship? And it looked like they were
trying to see how far they can go,
how much can we prevent
access to GitHub before people
start yelling at us?
Right.
And this went on for some days until at
some point GitHub was completely
unavailable. And I think the reason was a
circumvention tool that was posted
on GitHub and
there was some public outcry.
Right. People didn't just tolerate that.
And at some point
they ended up reverting
this thing. So they just unblocked it
again. And this is really a good example
here, that collateral damage really
hurts. Right.
And this is a useful thing for us to know
because we can design our circumvention
protocols in a way to maximize this
collateral damage.
But the system,
the Great Firewall is designed
in a smart way.
Right? So they came up with a way
to eliminate this uncertainty
and to gain certainty when all you have
is information to an encrypted protocol.
And what they came up with is
called active probing or that's what
we call it in our research paper.
And it's actually really simple to
understand. Right.
So, again, imagine a
connection and or pig connection between
a client in China and a server in
Germany.
So the Great Firewall
in the first step closely
looks at the connection.
Right. What is it?
Let's look at the handshake since it has
some information in there which could
help us learn what is in there.
And in the case of poor.
It's looking for something that is called
the cipher list of a
client. Hello, this is basically
a string that decline
sends to the server to tell it what
cyphers it supports.
And it turns out that this is more
or less unique to Tor.
So the project tries to adapt
it to a Firefox talking to an
Apache. And this works very well for a
while until Firefox moves
on and does something else.
So it's an annoying game to play.
Right.
And this is what the Great Firewall
leverage is. So they look at this and at
this point they might think, hey, look,
this could be a connection.
We're not completely sure because maybe
there is some unknown protocol out there
that looks exactly the same.
But we have no idea.
Right. We need to have certainty because
we if we end up blocking it and it's the
super important financial application
that screws with our economy,
then we are not much better off.
Right.
So what they do in the next step is they
launch a Short-Lived computer,
a short lived probe that connects
to the same server in Germany
and tries to speak to Tor
protocol. Right.
And this is just a guess.
They don't know if it succeeds.
They just go ahead and try it and see
what happens. Worst case, the server has
no idea what this garbage isn't, just
terminates the connection, but perhaps
it answers with a forensic.
And if that happens,
then the firewall has what it needs.
Right.
It sent basically decoy traffic.
It tried to fool the server into
replying. And when it did, it knows
exactly that. This is a Tor server.
And when this happens, you can block
it, right? You can just prevent access
and this is quite need from an
engineering point of view, since you can
do this without really bothering with
IP addresses and IP Chern and
Sipi, it's completely dynamic.
All you need to do is look at traffic as
it traverses the country border
and you inspect it and then
you probe stuff. Right?
So it's a two stage system.
In the first stage you do deep packet
inspection on a lot of traffic
and a small subset of the traffic.
It is suspicious.
And then to understand what it really is,
active probing is used.
And I'm talking about Tor here simply
because it's the most interesting
example.
So there are a lot of other protocols
that are that are being actively
probed. So in fact, the system
seems to be modular, right?
They can write easily modules for
additional protocols.
And so at this
point, what we did was a research
project, so we started compiling
our data sets.
So the first data set,
we ended up calling the shadow data set.
And it's basically what you
would do if you would tackle such a
problem. Right. You try to get advantage
points in China and
in two different ISPs.
Right. So there is UNIKOM, which is a
very large ISP in China,
and there is certain it which is short
for the China Education and Research
Network. And it turns out that the filter
is slightly differently.
Right. Which is quite interesting.
So not everyone is the same when it comes
to packet filtering. Right.
So some people have filtered more than
others.
And what we did was we had these systems
in two different networks and then we
repeatedly established Tor
connections to
bridges under our control.
So bridges are basically tor relays
that are unpublished for the sake
of censorship circumvention.
And we established three different types
of connection and normal tor connection,
which isn't particularly useful for
censorship, circumvention and
the protocols ABFS
two and three, which are
designed for censorship circumvention.
And we did that for a couple of weeks
over and over and over again every
approximately ten minutes.
Right.
So we ended up with a lot of connection
requests and we found out that
actually this wasn't this
wasn't as helpful as we expected,
since we didn't end up with a lot of
probing IP addresses.
So we created a second data set,
which we called the SIBYLLE data set.
And this is basically a client in China
that connected to 600 different
ports since we just used an IP
tables redirects to basically
fool the firewall into thinking
that we're running 600 bridges
on a single machine.
Right.
And it basically looks the same.
And that way we ended up with a lot of
different probing IP addresses.
And finally, we had a third data set,
which we call the lock data set, and
this is really just a Web server
whose log files go back
several years.
So it's really cool because you can look
at the logs and it tells you in some
way how active probing evolved
over time.
All right, so the first thing we were
interested in was where all these
IP addresses coming from, right?
So we looked at all three data sets
and all together we had a little bit more
than 16000 unique probing
IP addresses.
And you need griots, so there
is very little repetition.
Ninety five percent of them were seen
only once and we
also did reverse lookups
and we found string's like Edsel in
there. So it looks like all these IP
addresses or a lot of them originate
from ISP pools.
Right. And who is record basically
suggested the same.
So this is not a small part of IP
addresses that is reused over and over.
This is a large pool from
basically ISP pools.
And those are not users.
Right. The active probes, those are
automated systems.
So this was really odd to us.
And there is some set intersection and
there is one IP address among all of them
that shows up a lot.
So almost 50 percent of the probing
activity used to come from this single IP
address.
And this system seems to be somewhat
different from the rest because it
seems to be a dedicated scanning machine.
So I think it's not online
today. So don't bother trying.
It used to be recently, it also had an
open access port.
But
this.
But it seems to be a dedicated system
that is somewhat different from the rest.
Right.
And what this means
for us is I cannot just come up with a
block list of active probes and give it
to all you guys and say, just put this in
your I.P. table's rules and no prober
will ever show up again.
There are just too many of them.
Our list isn't even exhaustive.
There are more than that.
Right.
So our assumption was maybe there
are checking all these IP addresses,
right.
Maybe they don't even own them.
Maybe they just borrow them for a short
amount of time to probe and then give
them up again.
And it was really odd because it wasn't
possible for us to talk to these probes
other than to probe in connection,
so the scans didn't work because all
the ports were filtered.
We couldn't trace right to them because
trace routes would time out a couple of
hops before the destination.
You couldn't talk to the probe, so they
basically showed up at your doorstep, but
not the other way around.
So there wasn't a lot of interaction
possible. So we were left
basically looking for patterns in all
the data that we gathered.
And we did that in a systematic way,
going basically bottom to top
in the layer models.
So we started with
trying to look for patterns in the IP
layer.
And we didn't find a lot of interesting
stuff, you get a somewhat narrow
TTL distribution, which isn't
particularly surprising and can be
explained with rotting.
But we found much more interesting stuff
at the other layers, for example,
all these 16000, not all
of them, but a lot of them used the
entire 16 Beatport range
to source part range, which isn't
something you would find in many modern
operating systems since they don't use
the well-known port range as source
ports. But they did.
Right.
We also found odd patterns in the
timestamp value.
I'm not going to discuss that since there
is not enough time, but you can find the
details in our research paper.
And these things seem to suggest
that this might not be a normal
PCP's stuck in a KERNOHAN, perhaps it's
a userspace to protect your programing
somehow to maybe scale their probing
activity better.
We're not completely sure about that.
And the most interesting pattern
we found was in the initial sequence
number. So I'm giving you a quick
reminder how it works.
Tsipi initial sequence number are a
32 bit number in the header
of TCP segments,
and they have the nice property that they
protect you against off path attackers,
since attackers have to guess your
sequence number interval, which is
supposed to be hard.
Right.
And it does that by simply
randomizing initial
sequence numbers for the Atkisson
segment.
And this can be visualized.
Right.
So this diagram shows you the
distribution of a
lot of sequence numbers over time, over
a couple hours.
And that's the X axis.
And the Y axis is the value of
the initial sequence number ranging from
zero to four billion.
Every dot is a Tsipi
Sin segment that I captured.
And I didn't just make this up, so
this is actually derived from a modern
Linux kernel and it just made sense
in segments to a destination machine.
I extracted all the sins and prodded them
here. And it seems like a random pattern,
just like you would expect.
And you would expect the exact same thing
when you look at the probers.
Right, the active probes from China.
If you take all these sin segments and
you plot them, then you should see this.
But what we actually saw was
this.
And it's really weird, right?
It's a slightly skewed pattern,
it goes up like this and you can actually
connect the dots and then it becomes
a little bit more obvious.
And this is a zigzag pattern.
It goes up until it wraps back to zero.
Then it goes up and so on and so on.
And it turns out that the sequence
numbers are perfectly correlated with
time. So they simply derive sequence
numbers from the time stem.
Right.
That's what's apparently going on, which
is really interesting since this is not
one machine, remember.
Right. Those are the sequence numbers
from hundreds of machines across
a lot of different IP addresses.
So this is basically stately, kitsch,
red.
And we find more odd stuff
in the Slayer, right?
So when you establish or the Tor
protocol stack is you have TCP,
then you have Tlas and then you have to
talk protocol.
So on the Slayer,
we looked at the client.
Hello.
And again, it looks just
weird. It's not something a normal
application would send.
For example, there is no randomly
generated and I like tor
clients send them to servers.
It's just missing entirely.
Deciphers seems to be unique
as well. It's just not something that
your client would send.
And to get an idea of how unique it
is, we recorded
the cipher suits on a tour guard, really.
And obviously we did not record any IP
addresses. So all we know is basically
a frequency distribution of how popular
a specific cipher suit is.
So we ended up getting more than 200000
cipher suits in twenty four hours.
And the specific one
the probes use is super unpopular.
It's really just 67 entries
and we don't know where they come from
because we didn't record IP addresses.
But the point is this is absolutely
not common and maybe they were from
China. We don't know.
But it's really odd.
This is not something a Tor client would
send.
And if you go up the final layer
and this is what Proops do when they
connect to a bridge after establishing a
Tsipi connection, after establishing
a handshake,
they simply send a versions cell
to our bridge or a bridge responded
according to the protocol specification
with their versions, cell and inept
info cell, which is part of the
handshake.
And at this point, the probe
closes the connection, right?
It doesn't care anymore.
It doesn't bother creating a circuit
since it probably already knows what
it needs to know. Right, that this is a
Tor bridge.
It doesn't need to do anymore.
And again, but just
looking at how it does it, this is not a
reference implementation of a talk line.
It looks like something handcrafted in
a way.
And like I mentioned before,
there is a lot of leakage.
Right.
These probes leak state and we can
observe it across IP addresses.
And it's a really interesting question,
too, to think about how
this system is designed.
Right. And we have a bunch of sections
on that in our research paper.
And unfortunately, we don't have an
answer.
We have some hypotheses,
some of them maybe more likely than
others, we don't really know.
So maybe if you have some ideas,
you should get in touch with us because
we are really dying to know how this
thing works.
And one
hypothesis is that it's a proxy network,
that it's a geographically a set
of geographically distributed proxies
all over the country.
And the firewall somehow tunnell's
its traffic over all these proxies
and uses it to scan a server.
And personally, I think
that might be a little bit too much
engineering effort and it could be
done easier.
But again, our data is somewhat
contradictory and we cannot really rule
out any hypotheses.
A second one is that maybe they
have a server which is
sitting in a data center at an ISP
connected to a switch port, and
whenever they want to borrow an IP
address, they somehow update the access
controls on the switch and in check
packets and try to talk and basically
hijack the IP address for a couple of
minutes until they're done and
then they can give it up again.
But this is just a theory.
Unfortunately, we still
don't really know.
So I've talked a lot about the structure
of the system.
Another question is how well does it
even work?
And this is what our shadow data
dataset is able to to answer.
So we basically established connections,
if you remember, over and over again.
And every dot in this diagram
represents one connection attempt,
right? It either fails or it succeeds.
So the successful ones are on top
and the unsuccessful ones at the bottom.
And we have both for Senate and for
UNIKOM, our two ISPs.
And the one really cool thing
I want to point out is look at the top
lines of both.
So sometimes it succeeds
once.
And 25 hours later, it succeeds
again once
and this repeats right
sits a repeating pattern of being
able to establish a tour connection every
twenty five hours,
which is really weird.
So, again, we don't know why.
So one theory is that perhaps they're
flushing their blacklists
every twenty five hours and update them
again and maybe it takes a couple of
minutes. And in that time span
people can do whatever they want.
It's one theory, right?
And after all, it looks like all the
quality assurance for the Great Firewall
is done by academics anyway.
So you might as well trust us and
not the operators of the Great Firewall
on that. It's not clear.
So that's the the effectiveness
and.
How fast are these probes, right,
in 2012?
It looks like they were batch process.
So it looks like there was a Cronshaw
running on his system and every 15
minutes they would invoke that crunch
up to basically, you know,
process all the probing tasks.
And it seemed to work fairly well.
So this is a visualization
we created back then.
And apparently the system
was improved not
too long ago and they basically
turned it into a Real-Time system,
which is really interesting.
So this was derived from Arcibel data set
and on the x axis, you
can see the parts of our data set
from zero to six hundred.
So for every port you can see, how
long did it take to firewall for
a probe to show up and
the delays on the Y axis?
And you can see that most points
are very much at the bottom, so they show
up really quickly.
In fact, the median
arrival delay is really just 500
milliseconds. So most of the probes only
take half a second between
the initial connection from
a user and the follow up active
probe in connection.
So these days, it seems to be fairly
sufficient, fairly efficient.
And there are a bunch of outliers and
there we we cannot fully explain.
So you see all those peaks and then
they go down in a linear
fashion. We're not completely sure.
So I think a lot of these
a lot of these things represent
implementation artifacts of the
off the grid for a while.
But then again, in a way, we're doing the
quality assurance for the Great Firewall.
So I'm sure someone is going to learn
something from this diagram.
All right, so, so much for
the design of the system,
and I only talked about Tor so
far simply because it was the most
interesting example
since they put a lot of thought
into that. But there are a lot of other
protocols that are being probed
by the firewall.
And this is an incomplete list.
Right?
It looks like it started in 2011
when somebody wrote an article and
published it and wrote about how he
received those weird
SS packets from China with
a seemingly random payload.
And back then it wasn't really sure what
it was or what
it was used for. Right.
Since apparently it was just probing
activity. There was no blocking going on.
So probing doesn't automatically equal
blocking. Right.
There is a lot of probing going on and
never a blocking decision.
So maybe there is just experimentation
going on. It's not completely clear.
There was probing for open VPN for a
while for soft ether,
which is part of the VPN gate protocol
Torres already talked about
also for Google's apps.
But since there used to be a small
and really clever circumvention protocol
named Go Agent, and
I guess that perhaps they came up with
this probing activity to detect this go
agent instances
and maybe there is more.
I'm sure there is more out there and
maybe someone even has an idea.
So please get in touch with us.
And we also looked closely at
how the Great Firewall deals with
OBSS two and
three probing. Right?
And again, it doesn't take a long time to
figure out that there are oddities in
there you wouldn't expect in a
normal connection.
And again, it looks like they're just not
using reference implementations, which
I find surprising since all the
software they are trying to probe
from Tor to OBSS to in
three to open VPN.
It's all free software, right?
You can just download it from a website
and you can throw it into your probing
system and let it run.
But still, for some reason, all these
things seem to be handcrafted in a way,
maybe to be more efficient or maybe
nobody wanted to bother with figuring
out how to properly use the original
software.
It's not clear, but the ironic thing
is that this handcrafting makes it
possible for us to fingerprint
the active probes after they've
fingerprinted all the traffic from
circumvention protocols.
Right. Because just like circumvention
protocols, Leak stayed, the active
probing system does as well.
And what we find are things like
the padding that is being used in office
three looks somewhat different,
right? It's according to the
specification, but instead of sending one
TCAP segment to segments,
they're just sending one.
Right.
And we even found cases of duplicate
payload, which you really
shouldn't find in the data because
the payload is supposed to be uniformly
distributed. And the odds of getting the
same payload across two appearances,
actually, even for just one, should be
really low.
So in that case, two IP addresses showed
up and with an
identical payload.
Right. And again, it looks like they're
just looking straight all over the place.
And remember that we also have this large
data set, which is basically the logs
of a Web server, and it allowed us to
look back into the past and how
probing evolved over time.
And we ended up creating
this diagram
so we could identify a lot
of probes in the data.
We are fairly certain that
it should be free of false positives
and it dates back to 2013.
Right.
And the magnitude off
of the the protocols
refers to basically
how often we saw it in a given day.
And this is really cool since it gives
you some some idea of how the
firewall evolved over time.
Right.
Like I said, it's not completely it's not
a complete diagram, but we can learn some
things from it, like up to
the end of 2013, there was apparently
a lot of probing activity and then for a
couple of months, it almost
stopped. There's some trickle still
going on, but we don't know what was
going on at a time stamp.
It was just not that much probing.
We can also see how new
protocols were introduced and maybe
even tested. Right.
So that's really cool to to
see how all these things started
to happen over time.
But again, take it with a grain of salt,
since it's just not
complete. I'm sure there is more to this
than what we have captured in this
diagram.
And on our project website,
we have a bunch of instructions that you
can run on your Web servers or on all
your boxes to find your own probes.
Right.
And this can be as simple
as grabbing for a specific post
and get requests in your Web server logs
for software for for example, or for
the app spot probes.
And you could also test to be done for
this particular IP address, as I
mentioned earlier. So it looks like there
is no activity these days, but
that's probably a really foolproof way
to maybe get some interesting stuff.
And it doesn't do just probing for
circumvention protocols.
I've even seen that thing in my Web
server logs for some reason.
So maybe somebody can find some
additional information about that.
And the really interesting
thing about the the active probing system
is that it's active, right?
A lot of censorship systems
tends to be entirely passive, red
or mostly passive.
They just sit there, they wait for
suspicious traffic, and then they
terminate your connection or maybe they
drop protocols.
They do whatever it takes to make the
connection go away.
So they are more or less passive.
There isn't you cannot interact with
it in any way.
And this is entirely different for this
active probing system, because is the
name already says it's an active system
that connects to you, that talks to you.
It has to talk to you because otherwise
it cannot block you.
And the interesting thing is that
its nature, its active nature,
makes it possible to interact with it in
unexpected ways.
Right.
And we
don't have a complete list, but there are
a bunch of things you can do to to make
the life of the active probing system a
little bit harder. Right.
So one is how large
is the plotless staff really?
Right.
So we had this civil data set and we
redirected 600 ports to
a single port, which means that
we basically put 600 new entries
in their blacklist list.
But that's just 600.
Right. Every computer, every
IP address has more than 60000
ports and you can use
them. All right.
So every single IP address is
able to add 60000
new entries to the blacklist.
And that's what you can do with one
address. And then you can continue to
scale horizontally.
And a single 24 network
can add 16 million addresses.
Right. So imagine if all of you would
team up and do something like that.
So I guess it would be pretty easy to hit
the limits quickly.
And you can do something very similar for
file descriptors, right.
So file descriptors are US imposed
and it's not clear what the limit is for
this system, but by simply
establishing a lot of connections
and keeping them open, you can
maybe get closer to that limit.
Right. So you just attract a lot
of probes and then you don't let
them go away. Right.
You just don't sense data.
You establish a TCAP connection, but you
don't send them data.
So you keep them waiting.
Right.
And at some point they will probably time
out. So you probably have to scale it
horizontally, too.
But it's not clear what happens if
the system runs out of file descriptors.
Right. Will it just stop probing new
systems or what's going to happen?
It's not clear. So maybe this is a way to
just prevent
additional circumvention
servers from being blocked.
And my personal favorite is probably this
one, and I have to give credit
to the authors of the
paper, which is really great,
and VPN Gate
is a circumvention system
that is based on VPN servers.
Right. So the idea is you have a lot
of VPN servers.
I think they have several hundreds across
the globe. And you tried to give it to
censored users.
So they compile a list of IP addresses
and they give it out to users and they
then select a VPN server
that works for them.
And if
you were in charge of the Great Firewall,
the easiest thing to do would be to just
have a CRONSHAW that fetches this list
every day to just extract all the IP
addresses and the added to a blacklist.
Right. It's pretty straightforward,
but the thing is, this gives
control to the people who
run VPN gate.
Right. Or to whoever distributes
those nasty IP address lists.
Right. They basically can control
the blacklist of the Great Firewall,
which is insane.
Right. If you think about it.
And it's not just
about the IP addresses of VPN
servers, it's just IP addresses.
Right. So what happens if you if
you put Windows Update in there and
entire China is no longer able to update
their windows because the Great Firewall
is just randomly pulling in IP addresses
from a from a list?
The same is true for DNS root servers
to basically break DNS for a country
that way. And also Google infrastructure.
Right.
And they discussed this in
great detail in the
in the paper, so they have a bunch
of paragraphs, a bunch of sections in
there where they they really talked
about this cat and mouse game, which was
super fun to read.
And it was a matter of days, basically.
Right. They talk about on day
one, we did this and then the Great
Firewall did this and we reacted by doing
this.
And I think it only took two or three
days until the firewall operators noticed
that it was possible to inject arbitrary
IP addresses into block lists.
And at that point they started to verify
addresses. Apparently, it's not
completely sure how maybe to just
check to the address belongs to or
try to connect to it.
But the point is to make sure that don't
just swallow whatever you give to the
firewall read.
So that's precisely my
my favorite way to mess with the
firewall, and
so far I've only talked about how the
system works, but not much
about how it can be circumvented.
Right.
And it turns out that not
all is lost. And we still have a lot of
ways that
that we can use to to have connectivity
in China.
And a one way is to
just look at how the Great Firewall
deals with GCP segments.
Right. Since when I
talk about DPI, you probably just think
about pattern matching, right.
Finding byte sequences in TCAP
segments.
And there is actually much more to it
than that. Right.
Since you need to reassemble the TCP
stream, which is actually not
a trivial thing to do
if you are dealing with
network packets that were crafted in
a way to make this super hard
and that you can do right.
So to deliberately make
it hard for them to reassemble.
And we actually exploited that a
while back since at this
point the Great Firewall didn't
reassemble streams and maybe for
performance reasons, it's not clear why.
So after all, it's just simpler to scan
packet by packet without reassembling
the stream.
And we brought a tool that basically
manipulates the TCAP window size
on a server which can be used to
instruct declined to break
its signature into two pieces.
Right.
And that was enough to circumvent
the DPI engine.
Right. So you're basically just instruct
clients to break the signature into
two pieces and the firewall is no longer
able to identify it.
And this worked approximately for a year
until it was fixed and it was never meant
to be sustainable, but it was a nice
check anyway.
And there is even a research paper where
they looked at all these
nifty little hacks that you can do,
how you can format your TCP
segments in a way that it's really,
really hard for the firewall to actually
reassemble it, since there are a lot of
ambiguities when you're trying to do
that.
And this is really needs and some of
these things are really difficult to fix
for the firewall.
But unfortunately, it's also really
tricky for us to exploit.
Right. Since it really boils down
to me telling people to, hey,
why don't you just run this KERNOHAN
module I wrote over the weekend, write
it, manipulate your operating
network stack and in a weird
way, and the Great Firewall is no longer
able to scan the traffic.
But these things are just a nightmare
to deploy. And as a result, we haven't
really seen a lot of it.
Right.
And it gets a little bit easier with cool
APIs like the Colonel's
Livnat Filter API,
but still it's just not very
reasonable to deploy.
So what turned out to be much
more successful was the tour
project, pluggable transport
idea, and this
started a couple of years ago when the
tour project noticed that
actually it would be much
easier to fight this arms race if
we decouple the anonymity
part from the circumvention part in the
talks. And so we just take the
circumvention part and put it into a
separate
program, basically.
Right. So instead of two tourists,
server and client talking directly to
each other, what you have is an
additional proxy sitting right in
front of these two Tor instances and
descrambler traffic in a weird way in
between them.
But the Tor basically just talk
to an additional sock's interface.
And since it sucks, it's really
easy to use for a lot of different
applications. So the cool thing is
this is by no means specific
to Tor and in fact a lot of different
systems started using it.
So there is basically an open
specification about it at this
point.
And it's particularly useful for a lot of
VPN providers that are trying to
give access to people in censoring
countries rights. So they just put
a pluggable transport server, which
we usually call ABFS proxy in front
of it. And that often solves the problem.
And it's a really flexible system since
you can modify payload, just like you
can modify flow information, you can
deal with things like packet
lengths.
And there are also APIs for several
different languages. It started out in C
and then we noticed it's actually a
little bit cumbersome to write those
modules in C and then
we reimplemented it in Python and
there is also one to go.
And
on the right, yeah, you can see a
visualization of the of the
payload of Vanilla Tor versus ABFS
two and three, and every pixel
represents the value of it.
And the point of this diagram is
if you look at the top left, you see
that vanilla tor doesn't
look very random. Right.
And what do you see here is basically the
handshake, since
it just doesn't use the entire
the entire byte space in its handshake.
And this is what some circumvention
protocol for trying to fix.
And at this point, we have at least four
protocols that work in China.
So scramble suit and OBSS for very
specifically designed to
be resistant to active probings since
still rely on a shared secret
that is given out of bed, basically.
And if you cannot prove knowledge of this
shared secret in your network packets,
a scramble suit and OBSS for server
just won't talk to you, right?
And there is also Mique, which
is really exciting because it
makes use of the collateral
damage problem I mentioned in the
beginning.
So what it does is it tunnels,
all the traffic over a content delivery
networks. So that technique is also known
as domain fronting.
And this is really cool because the idea
is that if you are a sensor,
you are forced to make a decision.
Are you going to block this content
delivery networks and everything it
hosts, or are
you going to let all the users pass
and use it for circumvention?
And ideally, the answer to that is no,
I'm not going to do that because it would
be insane, because there are just so
many websites hosted on CDs
these days that it should just be too
much for a censor to do.
Right.
So that's the idea of Mique and
F.T. stands for format transforming
encryptions. And it's a new tack to
basically format arbitrary
bytes, streams according to a bunch of
regular expressions you you provide.
And the cool thing is all these systems.
This isn't just science fiction.
So they're developed, they're tested
and they're deployed.
So when you download Tor browser today
and you started, then you get actually
a window like that and you can select
whatever you prefer among these
circumvention protocols.
And a lot more of them are in
the making right now, like a Web RTC
based transport, which is going to fix
hopefully a bunch of nasty problems
and which looks really
promising at this point.
And that brings me to the
end of my talk, so we have a project
website where we have our research paper
and the data set.
And just like it should be with
scientific research, it's free and open
the code and the data.
And if you want to get in touch with us,
those are all our email addresses.
Thanks a lot.
OK, perfect.
Thanks so far for that.
We have about 13 minutes
left for questions.
So if you have a question for Philip,
please line up at one of the six
microphones in this room
so we can get you on tape.
And everybody on the screen can also hear
your question.
Hmm.
All right, then, uh, mic one, please.
Go ahead.
Thank you for the talk.
I got a question.
Are there any similar things
known to North Korean Internet or
do they censor in a similar way
or sense of it at all or,
you know.
Question is, if there are similar
systems in different countries and I'm
not aware of any. Right.
And I wouldn't be surprised if that
happens at some point since that kind of
stuff is easy to put into DPI
boxes but Western countries and then sell
it to to other countries.
Right. So I'm not aware of anything now,
but I wouldn't be surprised if it happens
soon, unfortunately.
OK, quick thing before
we continue the Q&A, please,
if you really do need to leave before
the Q&A ended.
Please do so quietly so we can,
you know, pay some respect to the speaker
and finish the Q&A.
So please, Mike, to go ahead.
You were wondering about the probes,
where they were coming from.
Many computers in China, they're still
running Windows XP and
there's a virus. Scanners are from state
state companies.
So what about the botnet?
Have you thought about that?
Right. That's a good question.
We thought about that and we cannot
rule it out. Right.
So our thought was it would
be hard to keep that secret, right?
I mean, then again, maybe nobody ever
noticed.
Maybe.
All right, Mike, three, please.
Did you do any analysis
in regards of IPV six
because of that complexity
and new challenges?
Right.
Unfortunately, we didn't.
So I hear that rumor a lot that
IPV six is censorship resistance
simply because DPI boxes don't support
it very well.
I don't know if it's true.
It sounds pretty cool, but unfortunately,
I don't have any info on that.
No.
All right, do we have a question from the
segment, Angel and the Internet?
All right, question
from Alex CP2
Has any engineer from the inside
leaked anything about the trade Channel
five?
Well, I'm not
aware of anything, but that's one of the
reasons our email addresses
are on the slide, I guess.
All right, then, just another
question from Iasi.
What what reason is
there to think that China only operates
probes from and inside
China?
I see.
So I guess it depends on the
infrastructure, too.
Maybe it's just easier technically.
And so there is a technical reason and
I'm sure there is also political reason
since you can do that in
your own country. But I guess if you
start messing with with that
stuff in different countries, that has a
huge political impact.
And I guess, you know, people
tend to be smart enough to not ignore
that. So, yeah, I think those
are the two answers that there are
technical and political reasons to
not do that.
But there is actually research that looks
at the collateral traffic of DNS
injection in China.
Right. DNS poisoning.
So traffic that traverses
China is also subject to DNS
poisoning, even though the sender and
the receiver are outside of China.
But that seems to be accidental as far
as I know.
OK, then, another question from the
microphone, please.
I was wondering if
if yeah, if they ever blocked the
source instead of blocking this nation,
IAC,
not by IP address, I think
so.
The interesting thing is
the block, I think the
the Sinak segment of
Tsipi connection, which
is kind of similar to that in which we
find surprising.
Right. So usually when you think you want
to block a Tsipi connection, you would
just drop the sin segment since it's just
the first part of the
handshake.
But that's not the case.
When you're trying to connect to a
blocked server,
the Sinak from the server is dropped
and we don't actually
know why. People had a bunch of different
theories ranging from
axis control lists of switches
to maybe
to fool people into thinking that
Traceroute succeed.
We're not completely sure, but in that
case, it's similar.
Yeah.
All right, then, another question from
our signal, angel, please, Cheney
wants to know, has anyone tried
to use the probes against him, like
preparing Honeyball when the probe
arrives, try to fingerprint it, analyze
it, exploit it.
Right.
I'm not aware of that, but again, I
think there are more ways for this system
to fail. Like what if you could
start adding all these
probe, triggering signatures to really
popular protocols.
Right. And all of a sudden the system
is supposed to scan all these targets.
So I'm not aware of anyone exploiting
probes, but I guess there are more ways
to.
Yeah. To trick them into doing things
they're not supposed to do.
OK, I think Mike Five has
been waiting for a while.
I just looked through my looks and I
found some of these requests, for
example, for the VPN
service, etc.
Do you need some more information for a
data set?
That would be amazing if you could drop
us an email. Awesome.
Thanks a lot.
All right, um,
I think we have plenty of questions from
the Internet, so we will go back to that.
Taxila is curious,
do you have any idea about the algorithm
that is used behind sequence
number, initial sequence number, the
Jeffrey probe's use?
We don't.
What seems to be clear is that they're
derived from time.
But the exact algorithm, how they do
it, I'm not aware.
OK, all right, then, back to make one,
please.
Do you have a clue about the technologies
that they are using?
I heard something of Western companies
that are involved in the Great Firewall.
I think there is actually enough Know-How
there to not having
to rely on that.
And yeah, the
technology is a good question, since it
looks like that might be a TCP IP stack
in USERSPACE and we are not sure
some if someone is an expert on that,
maybe they could
just look at the packets.
We have to pick caps online and maybe
infer what kind of userspace
Tsipi stack is used for that.
OK, all right, then, Mike three, please.
I'm now some impulsive
thoughts after hearing the theories
about the research, the sequence
numbers and also the IP
stack range.
I was wondering if you've thought about
maybe a single machine or a few machines
that are actually playing on behalf of
multiple addresses.
I've played in the past in a single
local area network that
was able to respond to packets
with different identities, with different
IP addresses.
So maybe if they could do that on a
higher level, they could
steal your identity and then send packets
with different from different IP
addresses.
Yes, asking you if you thought about that
or this could be possible.
I'm not sure if I fully understand,
but it sounds like something
to look into.
Yeah,
we have some more patterns in the
tickets.
Well, that actually suggests that there
are like a small handful of physical
systems, like maybe 10 of them.
Yeah, I've played a bit
in the past.
I was having a server and I was able
using a Python script to monitor
the traffic and respond to
requests from a single machine to respond
to the IP addresses.
So I would dynamically, dynamically
decide if I'm going to respond or
not. So maybe they
could be doing something like that on
a higher level and deciding whether to
respond on behalf of an IP or
not.
Just just an idea, right?
Yeah.
Thanks for the hint, OK,
because there's plenty of people who are
going to stay for another question.
And Mike, three, OK,
can you give an estimate on which
mechanism DNS
poisoning versus packet
inspection, which one is more effective
overall for this censorship thing?
It's a deep packet inspection is
basically just finding patterns
in inside
packets. Right. So you basically use DPI
to do DNS poisoning.
So maybe you meant the recent
injection as opposed to
DNS poisoning?
I'm not sure.
I mean, in comparison, if they
just block the IPS and prevent
you from accessing the server or if they
just say, OK, you can't access Facebook
dot com because we don't like the
website.
Right.
So it looks like countries are generally
moving away from IP addresses since it's
just a mess to deal with.
Right. Do you want to be independent of
end points and not deal with things like
IP, Address, Chern and that kind
of stuff and content delivery networks?
So it looks like there is a trend to
move towards
being completely dynamic and only look
at, you know, flying bytes instead
of endpoints because because
for the DNS poisoning that sounds like
it could be just solved with DNS
sec.
You just authenticate the responses
and you pick the one which is
authenticated.
Well sure.
I mean there are ways to fix
that. You could also just, you know, wait
until you get both responses and picked
the second one.
Yeah, I guess. Yeah.
OK, thanks.
OK, for the last two remaining minutes,
please be quick and precise with your
questions. Mike, to please.
There are a lot of papers about the
Jiefu. I went and
you talked about the fingerprints the
guy is using and
uh, does the research you are
doing on those fingerprints and the
publication of those researchers
lead to a change of those fingerprints
off the Great Firewall itself?
Right.
So that's a good question.
They change anyway over time, right.
People start using different systems
and those fingerprints change.
But we're not talking about days or weeks
here generally. So those changing
fingerprints, it feels like it's a matter
of months and sometimes almost
years. Right.
Since I guess there are just
not a lot of people working
at the Great Firewall who have time to
adapt to new technologies all
the time. So I guess the answer is they
do change. But I think talking
about it in public is not the
major driving force for the fingerprints
to change.
Are they, uh, adapting
them to we act on the research
they are doing in the Western world, or
are they just changing it from
for other reasons?
So I'm sure there is some adoption going
on. So one important thing is
nobody cares if you have your own
circumvention tool that is used by five
people. What matters to governments is
circumvention at scale.
Right. So no matter how good
or how bad your tool is at the moment,
thousands of people start using it.
They're going to look into it.
So that's that's what
really triggers people start working
on it.
OK, so we are unfortunately out of time,
so sorry for the remaining people having
questions.
Philip is going to stick around probably.
And also you've seen his contact details.
Yeah, huge applause.
Thanks for the.