Feds try Censoring Tor, Accidentally take down Microsoft Azure

On December 1st, 2021, Russia launched

an aggressive attack against Tor's

censorship circumvention methods,

initiating a prolonged and highstakes

arms race between the Russian Federation

and the TOR project that still continues

to this day. We're going to see how

various censorship resistance strategies

from the TOR project often leaves

nations with an ultimatum of collateral

damage. In one of these cases, which

we'll see later in the video, a

seemingly negligent move caused Russia

to accidentally block the entirety of

Microsoft Azure hosted services for one

day. There's been equally creative ways

of censorship and censorship

circumvention methods in other countries

such as China, Iran, and Turk Menistan.

However, this video is going to discuss

the battle in Russia. Most of the

information in this video was sourced

from various talks given by Roger

Dingledine, one of the co-founders of

the tour project. He has excellent talks

and tells great stories. So, be sure to

check them out if you're interested in

learning more. Let's say that you're a

citizen that wants to access information

within a nation that censors various

resources. Or let's say that you're an

activist or whistleblower and you want

to communicate with someone or

something, but you want to do so

privately. We know that you can use

various tools to encrypt your traffic,

but encryption is not enough. When the

feds try to investigate things these

days, they're not actually trying to

break the encryption, but they're

instead building a social graph of who

you're talking to, how long you're

talking for, what times you're talking,

and more. Tour is an anonymity network

built on distributed trust designed not

just to protect the contents of your

communications, but also the metadata

surrounding your communications. If you

want to learn more about tour, I would

suggest watching my previous video on

tour. Before we take a look at the

ongoing battle between Russia and the

tour project in more detail, let's begin

with some foundational information. Tour

is a network made up of nearly 10,000

tour relays. All of these relays are

publicly listed in a central directory.

This means that if a country wants to

block tour, they can simply block the IP

addresses of every single tour relay.

What the tour project does to circumvent

this is by having a pool of hidden

unlisted relays called bridges. If a

user is in a region that blocks tour

relays, they would need to use one of

these hidden tour bridges to initially

connect themselves to the tour network.

Once they're connected, they're able to

use tour normally. This creates a

cat-and- mouse game where the tour

project needs to try and find a way to

distribute these bridges to legitimate

users one at a time while keeping them

hidden from sensors. Once a sensor

becomes aware of a specific bridge, they

will simply block it just like the rest

of the tour relays. This method where

sensors try to block the IP addresses of

relays and bridges is just one way that

sensors can try to block. Another way is

by using something called deep packet

inspection known as DPI. With DPI, the

sensor actually inspects internet

traffic all the way up to the

application layer of the packet and will

attempt to block it based off the

protocol. If they spot traffic that

looks like tour traffic, they will block

it. Of course, it's no surprise that

tour tries to disguise its traffic in an

attempt to blend in with regular non-our

internet traffic. Originally Tor tried

to make its traffic look like HTTPS web

traffic mimicking the Firefox browser

talking to an Apache web server. The

rationale here is something called

collateral damage. If tour is able to

blend in with very important widely used

protocols such as HTTPS traffic, the

sensor would face an important question.

If they want to block to they could.

However, this would require blocking all

HTTPS traffic, which would their

own country's internet services.

Essentially, collateral damage means

that for countries to block tour, they

would also need to block some of their

own operations. By attempting to make

the price of this collateral damage as

high as possible, tour tries to make it

not worth it to have these countries

block them. Interestingly, in countries

like China, this concept is actually

becoming less effective in recent years

as a lot of traffic within China is

contained within the country without

leaving. This also doesn't work well for

countries like Turk Menistan who are

willing to accept large amounts of

collateral damage in order to persuade

people into paying off the government to

get access to an uncensored internet

connection. Anyways, back to the story.

It turns out that trying to exactly

mimic Firefox plus Apache HTTPS traffic

is actually quite difficult. Instead,

the tour project decided to split this

issue into two parts. In addition to the

tour network itself, they created a

concept of pluggable transports. These

transports try to blend in, only dealing

with reachability into the tour network

without getting blocked. Once you

successfully connect to the tour

network, the tour network itself deals

with the rest. There's multiple

different pluggable transports that

actually work quite well, allowing

citizens to access tour in countries

that try to block tour. For example, one

of them is called Ops 4. Ops 4 adds an

additional layer of encryption on top of

your regular tour traffic, removing all

recognizable headers. This means that

when the sensor tries to do deep packet

inspection running a protocol classifier

on internet traffic, they'll see a bunch

of different protocols for various

streams of traffic. But when it comes to

ops 4 traffic, the protocol classifier

won't be able to make a determination,

essentially outputting unknown protocol.

Now, the sensor faces quite an important

question. What do they do with all of

the unknown protocols? Do they block all

of them or do they allow all of them?

This is another important question of

collateral damage. If they choose to

block all of the unknown traffic, they

will inadvertently block a bunch of not

only obscure but also newly developed

protocols. However, if they choose to

allow the unknown traffic, pluggable

transports like Ops 4 will allow users

to successfully connect to Tour. This

has proven to be quite a successful

method of censorship circumvention as a

lot of countries are unwilling to block

all unknown protocols due to the amount

of disruption that it causes. Let's take

a look at another interesting pluggable

transport developed by the tour project

known as Snowflake. Snowflake disguises

your traffic to look like web RTC

traffic, essentially making your tour

traffic look like video chat traffic,

which is allowed in a lot of places. In

addition to this, because Snowflake uses

WebRTC, and browsers support WebRTC

natively, you can actually download

Snowflake as a browser extension in

browsers like Chrome and Firefox. Due to

the ease of this, there's actually a

large variety of volunteers that get the

Snowflake browser extension in order to

help proxy traffic for users in regions

that block tour. This has helped

Snowflake to become a very successful

and widely used pluggable transport. In

addition to ops 4 and snowflake, let's

take a look at another pluggable

transport known as meek, which is based

on a method known as domain fronting.

Domain fronting is a method that can

actually conceal the domain name of the

service you're connecting to. Let's take

a popular cloud service such as AWS,

Azure, or Google Cloud. With cloud

services, we get into the realm of

virtual hosting where multiple different

websites using multiple different domain

names will be hosted on the same web

server, possibly using only a single IP

address for all of the underlying

domains. Since multiple distinct domain

names are being hosted on a server with

only a single IP address, these domain

names will actually resolve to the same

IP address. In order for the server to

distinguish what website the user is

trying to reach, it will take a look at

the HTTP host header, which will specify

the domain name itself. Domain fronting

is a technique that takes advantage of

this. Let's say that you connect to a

service over HTTPS running on a popular

cloud provider. The more popular the

service, the better, as you need to pick

a service that the sensor is unwilling

to block. A lot of the time, content

delivery networks known as CDNs are used

for this as significant chunks of the

internet would not work properly if a

sensor were to block popular CDNs.

Essentially, many CDNs, especially

JavaScript CDNs, are considered too big

to fail. In this case, let's say that

you open up an HTTPS connection to

ajax.penetcdn.com,

which is being hosted on Microsoft

Azure. This means that

ajax.aspnetcdn.com

will be specified within the server name

indicator or SNI field during the TLS

handshake. Once you complete this TLS

handshake inside of the HTTPS

encryption, you can now specify a

different host header for the actual

website that you want to reach. Since

this is done inside of the HTTPS

encryption, it will not be visible to

the sensor. Essentially, you're using

encryption to get to one domain that is

allowed, but then reaching a different

domain under the hood that is not

allowed. Of course, both domains must be

hosted on the same cloud service. From

the sensors perspective, all they see is

that you're talking to a JavaScript CDN,

but underneath you're actually

connecting to a tour proxy that sends

your traffic into the tour network.

However, it's worth noting that most

major cloud providers disallowed domain

fronting in recent years. At this point,

we covered both bridges and pluggable

transports. In short, bridges are

unlisted tour relays serving as an entry

point into the tour network, and

pluggable transports are techniques and

software that attempt to disguise tour

traffic. In countries like Russia that

block tour, you would need to use both.

You would use a pluggable transport to

disguise your connection to a bridge,

which would then serve as your entry

point into the tour network. Remember at

the start of the video when I said that

the tour project needs to find a way to

distribute bridges to legitimate users

that need them without leaking them to

sensors, which would blacklist them. To

accomplish this, they use something

called bridge DB. The rationale here is

that users need to provide some scarce

resource in exchange for a bridge. For

example, they tend to require a unique

IP address block or unique Gmail

account, among other techniques. The

game of trying to distribute bridges to

users without letting the sensor learn

all of them is in and of itself its own

topic, which we'll see more of shortly.

This brings us to the arms race between

Russia and the tour project. In December

2021, all in a single day, Russia

blocked all public tour relays. They

blocked domain fronting with Meek, which

was set up to work with Azure. They

blocked all of the OBS 4 bridges they

could find, including the ones that were

supposed to be more difficult to find.

And they blocked Snowflake. One week

later, the Tour Project received a legal

notice from the Russian government

letting them know that they would block

tourro.org

and shortly after it was blocked. The

data shows a stark decline in direct

connections to public tour relays and a

corresponding increase in bridge users.

There's a lot that went into these

blocks, but one of the most interesting

parts is how they blocked the meek

domain fronting method. Domain fronting

at the time was set up to use Microsoft

Azure, specifically a Microsoft

JavaScript CDN known as

ajax.aspnetcdn.com.

If they actually would have blocked this

domain, this would have stopped a

significant chunk of the internet from

working as this is a very common CDN

used on websites throughout the internet

to load in JavaScript. After looking

into what actually happened, they

realized that they did not block this

domain. They actually blocked the IP

address that this domain resolves to.

You might be thinking, big deal. Why

would it matter if they block the domain

or the IP? They're blocking the CDN

either way. But actually this makes a

huge difference. You see, Azure does

something that most large services do

called Geodns.

Geodns actually lets DNS queries to

given domain names resolved to different

IP addresses based off where in the

world the DNS query was sent from. This

is mainly done for performance reasons.

For instance, if a user in North America

types google.com into their search bar,

it will resolve to an IP address for a

Google server in North America. However,

if a user in Asia types google.com into

their search bar, despite being the same

domain name, it will actually resolve to

an IP address of a Google server in

Asia. In fact, they also get multiple

different services within a single

provider to resolve to the same IP

address of an edge server that receives

all initial traffic and then routes it

internally. You see, the IP address that

ajax.aspnetcdn.com

resolves to isn't just for the specific

domain, but actually for all Azure

services. Since Russia blocked this IP,

they actually inadvertently ended up

blocking all Azure services being

accessed within the region of Russia.

After about a day, Microsoft took note

and ended up changing this region's IP.

Russia did not end up blocking the new

IP. Just 2 days after Russia's initial

block on December 3rd, a long and

detailed forum post would be published

to the tour community, severely

undermining Russia's attempt to block

tour. You see, it turns out that Russia

only blocked the main tour website

called to tourpro.org,

not the forum, which is being hosted on

forum. Project.net at the time. This

post, which was published in both

Russian and English, explained exactly

what happened and included detailed

steps for Russian users on how to

circumvent the block and request

bridges, which was seen by hundreds of

thousands of people. This post included

instructions on how to use both Ops 4

and Snowflake as the tour project was

quickly able to bring both of these

pluggable transports back into a working

state. Snowflake was an easy fix which

was pushed out a few days after the

initial block. When it came to Ops 4,

which requires Ops 4 bridges to be

distributed to users, they took quite an

interesting approach to hide new bridges

from being blacklisted by Russia. This

new distribution system was actually a

Telegram bot called Get Bridges bot that

distributes bridges to anyone that

requests them. So what stops the Russian

government from creating a bunch of

Telegram accounts and requesting a bunch

of bridges? It turns out that Telegram

account IDs are assigned numerically.

This means that you can know roughly how

old a Telegram account is based off its

account ID. The Tour Project simply

divided their bridges up into two pools.

It would assign bridges from one pool to

older accounts and bridges from the

other pool to newer accounts. Sure

enough, Russia created a bunch of brand

new Telegram accounts and blocked all of

the new bridges. However, the bridges

assigned to the old Telegram accounts

actually evaded blocks for several

months, proving this to be quite an

effective strategy. The tour project was

actually able to cooperate with a

Russian operative on the inside who

revealed some interesting information

about how these bridges were being

blocked. Let's hear it from Roger

himself. And also I should mention uh

the importance of having people on the

inside who want to tell you what's going

on. We got some interesting

communications from folks who run who

work in the censorship ministry in

Russia. And I don't want to write any.

Yes. CL. Excellent.

And I don't want to write any of the

words up there because I don't want

somebody using styometry or something to

guess uh which employee that was. But

they were telling us interesting stories

like uh my job is to uh download to our

browser and get bridges each day. And

when I get a a bridge, I put it in a uh

an Excel spreadsheet and I email it to

the sensors. So, this is that's the

world that they are living in. If you're

imagining some sort of high-tech

automated thing, uh that was not what

was going on in 2021, 2022 uh in Russia.

And I think that's still the case.

>> Now, all of this started in December

2021. Fast forward two years to November

2023 and reports start to come out that

financial institutions within Russia are

actually working with the government to

investigate people who use their bank

accounts or credit cards to pay for VPN

services. Thankfully, these bridges and

pluggable transport still seem to be

working for those inside the country,

which of course are all free of charge

thanks to donations and efforts to host

relays and bridges by volunteers all

around the world. This video only

discussed specific events that took

place in Russia starting in December

2021. However, there are equally

interesting stories taking place in

other countries around the world. I

think it's fascinating to take a look at

these games of cat and mouse on both the

sides of censorship and censorship

resistance. I'll close with one final

thought. Even though it looks like in a

lot of cases the tour project is able to

use these bridges and pluggable

transports to successfully come out

ahead in the censorship arms race,

there's something else to consider. Each

time a sensor does something in an

attempt to block tour, it forces users

to adapt. They need to learn more about

bridges and transports instead of just

using tour normally. And they need to

stay up to date with new developments,

patches, and updates in order to adapt.

For example, there was a temporary issue

with Snowflake in September of 2023, and

despite the tour project successfully

restoring its functionality, the amount

of Snowflake users didn't make a full

recovery. In other words, each step the

sensor takes causes the users to be

burdened, even if the tour project pulls

out ahead. So, it's not just a game of

winning the arms race, but it's actually

also a game of slowing down the pace of

the arms race as well. A lot of people

wanted me to make more to related

content, which is why I made this video.

If you'd like to see more similar

content or have any ideas for future

content, please let me know in the

comments. If you've made it this far,

you might be interested in subscribing

to the channel and checking out some of

my other content. And as always, thanks

for watching.