Turning Off The Internet: Technical Tactics Of State-Scale Censorship And Shutdowns - Reza Sharifi

Hello everyone. Uh today we want to talk about what happens and when countries actually decide to shut down the internet. I think this is not imaginable for most of us that one day we do not have internet but yes this happens. But before this uh today I'm an executive consultant with CGI but before this uh I was a network security network guy let's say and I have done lots of uh projects in this area but when it comes to my favorites packets is my first one protocols logics these are things that I really like uh to work with. So if you wanted to keep in touch with me, I'm too old for Instagram and too soft for Twitter. So

please use LinkedIn and it would be my pleasure. Before starting I just want to remind that this talk is solely a independent technical research. It's by no means it's a you know political messaging and uh all the opinions are mine. But the question is this was my story but does it happen in other countries? The answer is yes. Based on a study done by freedom of the net 2024 basically n uh 30 countries almost 30 countries are doing this from time to time at different scales. So it's not only the country in the Middle East. We have lots of big names like China for sure, Saudi Arabia, India, Pakistan, Turkey. These are all the countries that they are doing uh you

know internet censorship actively. But how actually this happens? This is where it gets technical. But before going into the tactics and the techniques, we have to uh recall that there are four major technologies that are shaping the modern internet encryption, DNS, BGP and fiber optics. The last one provides the connectivity. BGP ensures the network layer reachability. DNS translates domain to IP and encryption provides confidentiality, protects our privacy and integrity if authenticated. But for this to work, I mean the censorship, they need central points. With central points you can create control points. How? This is you. This is me internet user. We usually connect to a mobile network operator or a fixed internet service provider or a satellite

provider. Each and every of these uh providers they have their own gateways. These gateways are connected to domestic online services providers mean content providers, government online services and these are in turn connected to the national gateways. This is the central infrastructure or the architecture of internet in many of the uh countries uh in the world. But it's not the case with uh Germany to the best of my knowledge for example and I will tell you later but these gateways internally are interconnected how they are uh getting connected through IXP or internet exchange points. These are basically you know high-capacity switches that you know big internet providers are connecting directly and uh you know peering on uh top of this uh physical

connectivity but this is going to become the border between the user and the free world. But still these countries needs to be connected to the internet. Right? Here is the internet and internet is being provided by different tiers of uh service providers. Tier one, tier 2, tier three uh local, regional and global. So these tiers are shaping the big internet. And this is the structure that the national gateways are getting connected to these uh uh tier uh one or two service providers again through BGP. So this is the central infrastructure. But when it comes to tactics and techniques, it depends what layer we are talking about. If it is application layer, it is usually about DNS DNS poisoning, SNI

filtering. When it comes to transport layer, it is usually done by TCP reset injection by packet dropping, temp tampering and traffic throttling. In the IP network or in the network layer, IP blacklisting was the old one. BGP manipulation is the uh is very common. APN filtering is another one. When it comes to physical layer, they just unplug it. Okay. So, let's start with DNS. What is DNS? Machines use numbers. VR good with names. DNS translates it, right? Okay. But it's not that simple. This is the DNS based on the standard RFC 1034 1035 has basically defined this protocol and this is the header of the DNS uh protocol or DNS message. But one thing and this here down

uh presenting a standard healthy query response uh discussion between the client and the server, right? But here we have an ID. This is here the ID. The ID basically is identical between a pair of query and response. You're going to need it. But when it comes to sending query, this DNS message has to be transported over something. The very common one is UDP and it uses 53 as a port number. The next one is TCP again 53, TLS 853, DNS over HTTPS 443. These are the uh common uh transportation for DNS queries. But now let's talk about DNS poisoning. What is DNS poisoning? Simply you ask what is the IP address for Google and somebody tells you this IP and you trust

him but that guy is a fake one but still you trust it. This is DNS poisoning. Let's take this real packet. This IP address 100 100 you know 400. This is uh just anomalized uh uh version of it but it's real traffic. Somebody can can somebody please tell me what's what is strange in this picture? Anyone? Come on. What the third? What is it?

Yeah. But there is something very strange here. Imagine. Thank you. 888 Google 999. It's quad 9. I think these are all uh public DNS resolvers and very trusted. But look at the response for YouTube. It starts with what? 10. 10 is a private address. How come? How come 888 responds to my query for YouTube with a private address? Something's off. Agree. So now let's zoom in. This is my original uh query and these are the two responses. One is red, one is green. But let's talk about first the transaction ID. You remember it has to be identical between all the uh uh query and the all the responses. It is already identical, but one tells

an IP address from a private branch, but the other one it looks legitimate IP, right? But we have to dig in more. The first uh DNS dissection is belongs to the query. The second belongs to the first response and the last one belongs to the last response. Something is strange here but it doesn't lie in the DNS protocol. Look at here we have an internet protocol uh header here. Correct? This comes with an identification ID. that this belongs to IP header and it has a time to leave. What is it? 1728. If you check the RFC791 identification ID is being assigned by the sender. So if I have sent a query with an identification, the response

should has its own identification. But look at this green uh the red uh picture. What is it? 17 28 1728. But the green 47EA the what does it tell you? This red packet is just a copy of my own query. So something happened in the uh middle of the way. I have sent a query. a middle box just received that query, copied the packet and resend it to me. The only difference between the query and the response from the middle box is this IP 10 10. But it tells me something else as well that my this middle box whatever it is it has not dropped my original query and my query has already reached to the

final destination which is in this case 888 right this tells me because I'm receiving a response and this response is a leg a legitimate one and I can tell from first the transaction ID because it it tells me it belongs to my query and second it has a genuine IP header. But if I check the DNS cache on my machine after this uh uh querium response discussion, I will see in the cache 10 as the IP address for YouTube. How come? Good question. It is because our resolver The operating system takes the first response as the main one and it discards ignores the other packets. As simple as that. You see logics, protocols, packets, they do not lie. They just, you

know, they they are beautiful. Seriously, I mean you can make sense out of it. And this is how it works. But this is this was a DNS over UDP. DNS over TCP. What is strange here? TCP has a handshake, right? I send the first packet as a scene. Then I receive another packet in response with a scene and act flags, right? Set. And then I send an act. So I see these three packets. So the hand check went well, right? Then the client sends the original query, right? This one the in green standard query with this transaction ID. But what happens after that? This is TCP, right? I'm getting TCP retransmission. Is is there anyone that can tell me when

you will get TCP retransmission in network? Absolutely. When the packet is lost or for any reason the time out the timer that the application is using for that specific packet has already expired. So when it gets timed out then TCP the client send uh tries again and again and again and again. Hence you're seeing different retransmission packets here but it shows that the that middle box drops the pack this DNS over TCP straight. How about TLS? What is TLS? So it's an encryption transport protocol, right? It encrypts everything. So what does encryption mean? It should be only between me and the ultimate destination. Correct? And no one else should be able to make sense out of this uh conversation in the

middle of the way. Right? But it's not the case. How? Again, if you look at the TLS protocol and you uh read the uh RFCDS standard, you will see the TLS has its own uh handshake uh mechanism. And this handshake starts with sending client hello. But before this again, we have this three-way handshaking. But what happens after client hello? you know sending client hello from the uh uh the the source to the DNS resolver again TCP retransmission. So it means that that middle box whatever it is it is sensitive to DNS traffic that goes over TLS it drops it. How about DNS over HTTPS? At least we do not see any red thing here, right? And it's true.

It works. We have the TCP handshake. We have the client hello. Then the server hello application data. Application data. This is this is a genuine healthy TLS communication between source and the destination. So it works, right? That's a good news. So if next time I set as the client my DNS to use HTTPS as the transport protocol for sending and receiving the queries then the middle bus cannot do or mess with it right no it doesn't work the previous one was between clot flare This one is uh with Google DNS, right? What is the difference between these two? Again, the story is the same. Client hello, we send it, no response. We cannot hear about it again. So, it

drops it. But what was the difference here? Absolutely. Here we are using TLS version 1.3 but here we are using one two and you will understand why it is so that TLS 1.3 is somehow it looks you know resilient but 1.2 two is not any questions so far. >> How what >> okay that's that's very good question. Here is the answer. There's a big irony with encryption. And that irony is every encrypted session begins in plain text. That's how why does it mean so I just asked GPT what portion of the uh web traffic or responses or queries are encrypted? This is his response, not my problem. Seriously, but we can, you know, relate to it. It's it's more than 90%. Right?

So this protocol TLS accounts for more than 90% of the traffics plus another protocol it is called quick developed by Google and later were standardized but we have TLS version 1.2 2 and we have 1.3 it is standard uh number is 5246 and this one is 8446 and it there is a 10year gap between 1.2 2 and 1.3. The big difference am I at five already? >> Okay. So, the big difference is between the negotiation the handshake. But if you want to know in the TLS version the there is a field in the client hello which is being sent in plain text and this SNI shows the actual target server and again this is plain text that's how

the middlebox can understand and provides enough information for the middle box as to what is the uh intention of this traffic. If it is not something that I do uh I do not like then I drop it. This is how right and there are some other ways of doing you know uh uh you know messing with encryption. One is protocol fingerprinting. This is done again by the middlebox. You can later uh check uh JA3 and protocol degrading for example quick as a very nice uh encrypted uh uh protocol has nothing uh you know it doesn't work in many other countries why because it's very secure and they do not like it and they drop it that simple.

Finally, the BGP. BGP is the routing protocol that shapes the net internet. Right? This is the standard for BGP. But I want to show you here there is a peering relationship between routers on internet when it speaks uh you know BGP. And this peer peering is between one AS and another AS. This is a logical uh you know boundary for any network inside the internet. In the free world if it is physically or uh you know visible every as can you know create a peering relation uh uh between one another but it's not the case again in many censored areas or countries. So they drop it. They do not allow it. Because if you can do this, then you can

circumvent all these middle boxes. Right? A healthy BGP relation starts with one as the the legitimate one sending and advertising the IP address with showing the AS number of himself as the origin and this propagates all the way across all these AS's that have pairing with one another until the AS that uh I as the user is connected to right and this is how when I want to get to one one and if I trace road it I will send my packet to the gateway of this AS this as this AS and then it gets to this AS and I will receive the uh you know reply message. But when it comes to BGP hijacking,

something uh strange happens. That as that one wants to hijack the BGP, create a fake advertisement of the same IP address and propagates this wrote down to the local ASS and in the result what happens here is that when I want to access the legitimate one basically I'm being re rerouted to the fake DNS this is how it works but sometimes it gets really messy when the AS or either intentionally or by accident leaks this fake wrote into the up uh you know upstream peers. When this happens, you will see this news headline here. Telegram is being hijacked and all the traffic globally or part of the uh you know in the world were being redirected

into a road that was not safe. This is BGP hijacking. And finally in the layer if nothing works they just unplug it. And this is how we finish. Thank you. Thank you.