Hey everyone, my name is Kevin Bock from the
University of Maryland. Before I get started,
I wanted to give a huge shout out to all the IETF
organizers for making this event possible,
doing all this remote organization, and I wanted
to give a big thank you to all the collaborators
on this project. It's really taken a village to
get this going. Now I'm going to be talking about
censorship today, and specifically a new form of
censorship evasion we've been working on,
server-side evasion. Before I get into that
though, I wanted to give you all a brief
background of
what nation-state censorship looks like nowadays
to motivate some of the approaches we've taken.
Now there are many types of censorship that
operate around the world today,
and today I'm going to be talking specifically
about the automated in-network censorship that
operates in the network by nation-states. Now
some nation-states operate censorship as in-path
sensors, like this one, with the sensor
physically sitting inside the network path.
Other sensors operate censorship like this.
Instead of being in the path, they're on the path,
so if the client makes a forbidden request, you
can see this request moving through the network.
Now the server will get the packet, and the
sensor will too. If the sensor wants to sensor
this
connection though, it can't drop it anymore
because it's no longer in the path. So instead,
it performs deep packet inspection on this packet,
and if the packet contains something it disallows,
what it will do is it will inject its own packets
into the connection. Specifically, it will inject
spoofed TCP reset, or teardown packets. These are
normal packets our computers send all the time,
these just exist to tell the other side, "stop
talking to me immediately." It's going to send
one of these packets to the client, pretending to
be the server, and one of these packets to the
server, pretending to be the client. Now when
these packets arrive, the client thinks the
server
terminated the connection, and the server thinks
the client terminated the connection. Immediately,
both of these sides stop talking to each other,
and just like that, censorship has been achieved.
Now in order to pull off this attack of injecting
teardown packets, the sensor needs to have some
information about the connection. It needs to
know the port numbers, the sequence of
acknowledgement numbers. What this means is that
the sensor requires per flow state, and that
means
that these sensors have to be tracking the full
state of every TCP connection coming into and out
of their country. And if you're trying to track
every single connection into and out of a country,
at a country the scale of something like China,
you're going to necessarily have to start taking
some shortcuts. And we as evaders can take
advantage of some of those shortcuts. So let me
give you an example from prior work of how
researchers were able to take advantage of these
ideas to evade censorship. Now once again, our
client is about to generate a forbidden request
to this resource, but this time we're going to
inject a TCP reset packet of our own. We're going
to set it in such a way that the TTL, or time to
live, this is a field in these packets that
will tell the network how long it should survive
in the network, and it decrements once per hop.
We're going to set the TTL high enough such that
we reach the sensor,
but not so high that we reach the server. So
watch what happens when we send this packet.
Now just like before, the sensor will get a copy
of the packet, but the packet's not going to
reach
the server. It's going to get dropped along the
way. Now the server never saw this packet, but
the sensor has, and the sensor says, "Well, it
looks like the client just terminated this
connection,
so I can stop tracking the connection now," and
it throws away the state it's been maintaining
about the connection. Now for the rest of this
flow, the client and server are free to
communicate.
The sensor has no state with which to censor us,
and the server has no idea we pulled off this
trick.
Now this is just one example of these strategies
that have been developed and discovered over the
last 10 plus years, and the one thing they all
have in common is that evasion has always
involved
the client, and that statement is true even
beyond ways and mechanisms of evading censorship
that do
not rely on manipulating your packet stream.
Consider Tor or VPNs or proxies. All of these
things require the client to install some
software on their system or take some direct
action to make
them happen. This has always posed a significant
barrier to deployment, though. Installing the
software can pose significant risk to the user in
the first place, and beyond that, it can help
users who either don't have the technical know-how
to set these tools up, aren't comfortable doing
so,
or even those users who don't even know they are
experiencing censorship in the first place.
Now ideally, servers would be able to help.
Instead of deploying software at the client,
instead we would deploy it at the server, and if
such a thing were possible, then the server
could subvert censorship on the user's behalf
without clients needing to deploy anything at all.
And just think about the benefits of this. This
would immediately broaden reachability
and accessibility for these resources without
clients needing to do anything. Many clients
connect to one server, clients no longer need any
technical expertise or to download anything,
every client immediately gets plausible deniability,
and it helps all those users
who don't have technical expertise or don't know
they're being censored in the first place.
So this sounds amazing. The problem is it shouldn't
work, and it shouldn't be possible.
And to see why this is, let's consider the
waterfall diagram of packets that are exchanged
leading up to some censored query. Client's going
to send a SYN to which the server responds with
a SYNACK, the client completes it through a handshake,
and then the censored keyword is sent.
From the server's perspective though, there's
very little it can do before the censored keyword
is
sent. In fact, the server can't influence this
connection past the SYNACK at all. Underscoring
the difficulty in this space, there's been no
prior work on evading censorship from the server.
Now, I'm thrilled to tell you that server-side evasion
is indeed possible. In the rest of this
talk, I'm going to talk about how we discovered
these server-side techniques and our results
across multiple different countries and protocols.
And then I'm going to talk about the insights we
glean from the sensors in these experiments.
Before I jump in to discovering server-side
evasion techniques, I wanted to first give you a
little bit of background on the tool we used and
modified to discover these strategies and get
some insight into this idea. Now, this tool is
Geneva.
Geneva is an open source, originally client-side
tool that my team built a few years ago for
automatically discovering censorship evasion
strategies. This was originally published by
my team in 2019. Geneva runs strictly one side of
the connection. We originally designed it for the
client side. And the way it works is it manipulates
packets as they enter and leave the system. Now,
Geneva is a genetic algorithm. So in fact, it
learns how it should manipulate packets.
Specifically, the way it can manipulate packets
is it can do that with just four actions.
That's duplicate, you take one packet, you get
two packets. Tamper, you take a packet,
you change it in some way. Fragment, take a
packet, break it in half. Or drop, take a packet,
you drop it on the floor. Now, I'll call out two
things specifically here. The first is that
tamper is allowed to alter or corrupt any TCP/IP
header fields. Importantly, we don't give it any
semantic understanding of what these fields mean.
We give it syntax, but not semantics.
What this means is that it can access the TCP
flags fields. It can change the flags fields.
But it has no knowledge that if I set the flags
field to sin, that means the start of a
connection.
So syntax, no semantics. Also call that fragment
here, it does a bit of double duty.
The IP layer does fragmentation, but it can also
do segmentation of the TCP layer.
So let me show you what it looks like when Geneva
puts these actions together.
Because Geneva actually composes these things
into trees. And these trees look something like
this.
At the top, we have some sort of match or trigger.
And then associated with that match,
we have an action. These are match action pairs.
And a strategy is comprised of some
combination of these match action pairs. So for
this specific strategy,
the trigger is outbound TCP packets, where the
flags set to ACK. When that match happens,
when a packet matches that trigger, it gets
pulled into the tree. And then the tree decides
how that
packet should be modified. The duplicate action
makes two copies. And you can see different
things happen to each copy. Then we do an in-order
traversal of the leaves,
and we send the packets that emerge. So let me
show you what this looks like on the wire.
Once again, our client has just finished the
three-way handshake, or they're about to finish
the three-way handshake. And they're about to
make a request to this forbidden resource.
We're going to generate our ACK packet, which
matches the trigger. Geneva pulls it into the
tree, duplicates the packet. The left child is
done. The right child, the flags are changed to
reset. The TTL is changed to two. And then in-order
traversal of the leaves, and we send the packets.
And if you'll notice, this tree exactly implements
the censorship evasion strategy
that I opened this talk with. This is the TTL
limited reset.
Now for this work specifically, we modified
Geneva so that it could run on the server side.
Then we deployed it against real-world sensors.
In our previous work, and a lot of other previous
work in this space, we've tended to focus on HTTP.
In this work, we've brought in the protocols that
we try and subvert censorship for. So
specifically, we look for HTTP, HTTPS, DNS, FTP,
and also SMTP
censorship. Now triggering censorship for these
protocols largely involves making requests or
queries with forbidden keywords and domains. SMTP
is a bit of a special case. For SMTP, you can
just
send an email to this email address. This is censored
in China. And for context, this email
address is an old mechanism by which how bridge
nodes used to be distributed in China. So the
email is censored. To show how this could be
applied broadly, in addition to the diversity
of protocols, we also tested against the
diversity of sensors, and both how these sensors
operate
and where they're located. So we tested in China,
Iran, Kazakhstan, and India across all of these
different protocols. Now I do want to note there's
a small asterisk on the slide. This refers to
that
although Iran censors DNS over UDP, at the time
of our testing, DNS over TCP was not censored
from
any of our vantage points. Now recall that server-side
evasion shouldn't be possible in any
of these cases, because the server can't really
influence the connection past the SYN act.
But Geneva was able to find ways to do it, and I
would love to show you what some of those things
look like. So this is one successful server-side
evasion strategy that works in China. Now there's
a lot going on here, so let me break this down.
The client starts off just like normal by sending
a SYN packet. Now instead of the server
responding with a SYN act, it doesn't respond
with the SYN
act anymore. Instead it responds with two SYN
packets. The first is a normal SYN packet.
The second is a SYN packet containing a payload.
Now this amazingly is legal. The first SYN packet
serves to trigger a TCP simultaneous open. This
is an archaic feature of TCP that's still
supported
by every major platform, and this was originally
written to handle the case of what happens if two
computers send a SYN packet to each other at the
exact same time. Now when the client receives the
SYN packet, the client now sends a SYN act. And
it's actually this combination of the client
sending a SYN back, the client sending a SYN act,
immediately preceded by a SYN packet containing a
payload that causes the Great Firewall of China
to desynchronize from the connection. And for the
rest of this flow, the client and server can now
communicate censorship-free. Now this seems crazy,
but this actually works with varying degrees of
success across all the protocols we tested. And
for context, the baseline success rate if you do
nothing at all for evading censorship is about 2%.
And this is one successful strategy, but it's
actually just one of many. Altogether, we found
11 different strategies at the time we did this
work. We discovered eight in China, one in Iran
and India, and another three in Kazakhstan. Now
our paper goes into detail across all of these,
and unfortunately, as much as I would love to, I
don't have time to go through them all now.
But I would love to show you just one or two more.
The next one I want to talk about takes
place in Kazakhstan. This is the null TCP flags
server-side evasion strategy. You'll notice it
starts off just like all of them do, the client
sends a SYN. But the server, instead of
responding
with the SYN act, instead of what it responds
with, is a packet with no flags at all. Now the
client,
when it sees a packet with no flags, it has no
idea what to do with it, so it just drops it and
ignores it. But when the sensor sees a packet
with no TCP flag set at all, the sensor can't
handle
it and assumes there's something wrong with the
connection and immediately stops tracking the
connection. And just like that, the server has
helped uncensor the client. Now one of the big
takeaways from this is that it really has helped
motivate why we should be using automated
techniques to discover this. This is likely a bug
in the sensor that it may have been difficult for
a human to discover. Now here's another example I
wanted to show you, also in Kazakhstan.
Now in this one, during the three-way handshake,
instead of the server sending one SYN act,
it actually sends two SYN acts, and it includes
payloads on those SYN acts. Specifically,
the payloads it includes are two uncensored GET
requests, GET requests for something like
example.com or something innocuous. Now of course,
the client is just going to ignore these payloads,
but when the sensor sees these well-formed HTTP
GET requests on these SYN acts,
the sensor confuses the connection direction. It
says, "Whoa, the server is sending this data.
I must have had this mixed up. The server must
actually be the client."
And it reverses the roles of client and server in
the mind of the sensor.
As a consequence of this, because it treats
packets differently from the client and server,
when they begin communicating again, and when the
client issues the real censored query,
they can now communicate scot-free, because the
sensor is now communicating with the client.
And this works with 100% success rate in
Kazakhstan.
Now at this point, we've seen a lot of different
types of bugs and sensors,
not handling esoteric features in TCP correctly,
error cases, or just confusing the logic
altogether. For more details for any of these, I'll
refer you to the paper, but it will note
that all of these do not require any client
behavior whatsoever. They may induce some
behavior from the client, but no software changes
is needed. And we tested this across a wide range
of diverse clients. And in fact, we found only
one case of a strategy that relied on platform
dependent behavior. We were able to very quickly
rewrite that strategy to make it platform agnostic.
And all of these really teach us more about how
sensors work.
Next, I'd like to talk a little bit more about
the insights this work has helped provide us with.
The first thing I'm going to talk about is
something called the resynchronization state.
This is a feature of the Great Firewall of China
that allows it to be more tolerant to packet loss.
So specifically the way this works is let's say
the sensor misses a packet.
The idea is simple. It can just resynchronize its
state on a later packet in the connection.
Now the exact dynamics of the resynchronization
state are constantly evolving over time.
And understanding how the resynchronization state
operates allows us to build better
sensor-driven evasion tools. So looking at the
resynchronization state gives us
some more insight as to why that first strategy I
showed you actually works.
So once again, here's that strategy. And I'm
going to focus right now on the second SYN packet
we
sent from the server. If you recall, we sent this
SYN packet, again, we sent it from the server,
but we sent the SYN packet including a random
payload. We notice here is that this payload
actually triggers the Great Firewall's resynchronization
state. It tells the Great
Firewall, hey, you may have missed something. Go
resynchronize on the next packet. The next packet
that it resynchronizes on is the SYNACK packet
from the client. But because we force a TCP
simultaneous open, when you do a TCP simultaneous
open, the mechanism by which sequence numbers are
incremented during the three-way handshake
changes. And the Great Firewall is not properly
incrementing its initial sequence number while it's
resynchronizing. What this effectively means
is that this is an off-by-one bug in the Great
Firewall of China. The sensor is not properly
incrementing its ISN, making it desynchronized
from the rest of the connection because of the
presence of this payload. Now, strangely, the
success rate of this varies greatly by protocol.
And in fact, we found that the Great Firewall
itself has a different resynchronization state
depending on the protocol itself, which is
strange. And this is just the first example
of protocol variability we found in the Great
Firewall. And I'm going to talk about that a
little bit more next. Now, all of our server-side
strategies operate strictly during the three-way
handshake, which means they happen before there's
any application layer-specific data going on.
We realized, though, when we started looking at
the success rates of these strategies,
is that they didn't always work the same way with
the same degree of success.
This led us to raise the question, why are
different applications affected differently
in China if the only actions a server takes are
done before there is any application layer data
exchanged? What this has led us to think about is
a new model of how the Great Firewall of China
works. Because in the past, we've kind of tacitly
assumed that the Great Firewall works with this
kind of very sane network model, where it sanely
separates application layer from transport layer
protocols. It looks something like this. But what's
going on here is that we're finding different
TCP layer bugs for each protocol, which means
that each protocol censorship must have its own
TCP/IP stack. And this strongly suggests that the
Great Firewall is actually running multiple
censoring middle boxes in parallel. It's not just
one set of machines.
So let's see what this looks like. Instead of
just one monolithic sensor,
instead we think there are multiple censoring
middle boxes, and each of these are running
in parallel. Now, this begs the question, how
does the Great Firewall know which middle box
to apply to a connection? Now, you may look at
this and be like, well, it's obvious. It's just
got to be using the port number. But it's
actually not relying on port number. The Great
Firewall,
all these protocols, can censor effectively on
any port. If you try and make an HTTP request
for some forbidden content on 80 or 8,000 or a
random port, it will still censor you the same.
So it's not using port number. What we think is
going on is that, how does it know which middle
box to apply? We think it doesn't. And we think
that every single little box gets a copy of every
packet independently. And then every middle box
applies protocol fingerprinting. Every middle box
checks, hey, is this something I can censor? Does
this belong to me? Does this belong to me? And
then if it discovers, hey, this is something I
should be taking action against, then that
specific
middle box will take action. This raises the
question, where are these guys located? Are they
nearby? Are they far away? So what we did was we
used TTL-limited probes. We sent forbidden
queries
for different protocols with different TTL limits.
And we tried to see, are these located in the
same
spot in the network, or are they located far away?
What we find is that largely, they're
co-located at the network level. They don't seem
to be located at different locations.
Now next, I want to shift gears a little bit. And
I want to talk about where we've taken these
ideas
since we wrote this paper. Now the first thing I
want to talk about is how this idea of service
idevation and this idea of an automated approach
to service idevation has allowed us to be highly
responsive to new forms of censorship. Back in
February of 2020, Iran launched a new form of
censorship called a protocol filter. The way this
works was that it monitored all protocols
entering and exiting the country on certain ports.
And it only allowed certain of those protocols to
happen. It performed protocol fingerprinting
across all of these. And protocols that didn't
match
were then subject to censorship, which means if
you tried to use a protocol they didn't approve
of,
regardless of what you were doing as innocuous,
they would take that connection down.
In fact, the only connections they did allow were
those that were able to be filtered by their
standard censorship system. So within a small
amount of time of this censorship system being
deployed, we threw Geneva at this problem. And we
were able to discover four strategies to evade
this filter, four from the server side. So this
means that as soon as Iran rolled this out, we
were able to defeat this thing and help roll out
those evasion tactics to those in Iran.
Another example of new censorship events that
occurred is last summer, China began censoring
the use of encrypted SNI. This is a new feature
in newer versions of TLS, whereby the SNI, or
server name indication fields inside TLS is
encrypted. Now the SNI field is revealed in TLS
1.2, where when a client connects to a server,
the client announces in plain text, the domain it's
trying to get to. SNI is clearly a privacy leak,
and the TLS developers are working on fixing that.
But SNI is how censors have been censoring HTTPS
for quite some time.
ESNI, people have been looking forward to, is a
mechanism by which they can protect themselves
from SNI-based censorship. And unfortunately,
last summer, China decided to ban the use of
ESNI completely. So if you try and encrypt your
SNI field in any connections, China will take
action against that connection, even if you're
talking to something innocuous. And it's
effectively
stopped the rollout of ESNI within the country.
Now, within 24 hours of China rolling out the
system, Geneva had discovered six strategies to
evade it, six from the client and four from the
server. So this is very exciting, and it really
allows us to be highly responsive and dynamic as
new censorship events occur. Now, the other
exciting direction we've been able to explore
since this work has been a real-world deployment
of this system. And we've been working with a
number of anti-censorship groups to integrate our
software and our findings into their systems.
And we're starting to see success with this. We've
been using Geneva to help really in two
regards. The first is in bootstrapping initial
connections. So let's say you're something like
a VPN, and you really want to help users get
connected initially. And the weak spot in a lot
of these protocols is that initial connection, is
those API calls, that initial reaching out.
Now, what we can do is use Geneva to help protect
those initial bootstrapping and assist in
bootstrapping clients from a weaker protocol to a
more secure protocol. The second thing we've
been able to help with is in hardening existing
evasion protocols. Evasion protocols that censors
may be working on harassing or taking action
against, use Geneva on top of those and deploy
these server-side strategies to protect those in
use and make it harder for censors to take action
against these. And we're very excited about these
new directions. I want to conclude here to talk
about new directions that this work has opened up
for us, and really how it's changed the way
we conceptualize middle boxes. Because these
middle boxes are really creating new
possibilities in the
network. It's good because this has opened up the
ability to do censorship evasion to more people,
even those who don't know they're being censored.
Now, this is made possible though by the ugly
fact
that middle boxes have bugs and bad assumptions
that can be exploited.
And unfortunately, this can also lead to some
very bad directions. In another recent piece of
work,
we show that middle boxes can be actually weaponized
by attackers to launch attacks that
were long thought impossible. Ultimately, this
leads us to conclude that to really make sense
about what these new additions to the internet
are doing, we really need to keep investing in
automated tools like Geneva to understand what
new things these middle boxes enable,
and how they change the landscape of the network
and networking research.
Now, I'm going to wrap up here. Today, I've
talked about Geneva and specifically how we've
applied it to make server-side evasion possible.
If you want to learn more, our website is
available
here at the slide. It's geneva.cs.umd.edu. Thank
you all very much.