Airtel is sniffing and censoring CloudFlare’s traffic in India and CloudFlare doesn’t even know it.

Note: This is largely due to the work done by @captn3m0 and @shantanugoel. I’m merely writing this because they are too lazy to.

TL;DR — Airtel is sniffing and intercepting ALL unencrypted traffic going upstream from CloudFlare’s India data centres, irrespective of what ISP the user is on. This potentially affects everyone in India accessing ANY of the 2 million+ sites on CloudFlare.

It started when we discovered that The Pirate Bay was showing a blank page and was attempting to load an iframe to http://airtel.in/dot, which is a notice saying that the site is blocked as per the Department of Telecom’s orders.

This is fairly routine, there are a ton of sites blocked in India without explanation, and it’s very common to find vague notices like this.

But this one was particularly interesting for a couple of reasons, firstly, we noticed that this was happening on a HTTPS page, with a valid certificate.

We hit https://thepiratebay.org via a VPN and it loaded fine, and we confirmed that the certificate for CloudFlare were the same and valid.

So Airtel couldn’t have changed the page to show that notice. Unless they had CloudFlare’s certificates, which was super unlikely, and in anycase we ruled out since the exact same page was shown to people who on non-Airtel networks as well, with a link to Airtel’s notice.

One possibility: Is CloudFlare itself serving the notice?

Since this wasn’t specific to Airtel’s network, but was happening to everyone across India, we figured that maybe CloudFlare itself was blocking it. This would explain why it was served over a valid HTTPS connection.

On the other hand, is there any legal grounds for the Department of Telecom to ask CloudFlare to block anything? They aren’t an ISP.

Moreover, why would they embed an iframe that links to Airtel’s block message?

That seemed unlikely.

Is CloudFlare’s upstream network being censored?

The most plausible explanation then was that CloudFlare was thinking it was talking to The Pirate Bay and was completely unaware that it was actually getting a response from Airtel saying the website was blocked.

There was some evidence that supported this theory,

The iframe’s URL had a ‘userip’ parameter that (we assumed) referred to the client’s ip.

In this case, all the IPs were CloudFlare’s (Their IP range list includes 162.158.0.0/15).
Okay so it’s likely that Airtel was serving this page between CloudFlare and The Pirate Bay.

How does Airtel know who CloudFlare is talking to?

CloudFlare talks to The Pirate Bay directly via its IP, and one of the advantages advertised by CloudFlare is that you can mask(and change) the Origin’s IP from the public. You and I (and Airtel) can’t know the actual IP of the server, so how would Airtel know which requests to intercept and show the block notice to?

We figured that Airtel probably doesn’t know, and was perhaps looking at the ‘Host’ header of the request to figure who CloudFlare was talking to, and that CloudFlare and The Pirate Bay had to be communicating over unencrypted HTTP for this to be possible, that’s the only way Airtel could look at the headers. This was easy enough to test.

We made a request to a random IP address(In this case, GitHub’s) with the Host as ‘thepiratebay.org’ and we got a valid response when we ran this this on a non-Airtel network — A 301 redirect.

>curl -H "Host: thepiratebay.org" http://192.30.253.112/ -i
HTTP/1.1 301 Moved Permanently
Content-length: 0
Location: https://thepiratebay.org/
Connection: close

But when we tried the same thing on Airtel’s network, sure enough, we got served the block page.

curl -H "Host: thepiratebay.org" http://192.30.253.112/
<meta name="viewport" content="width=device-width,initial-scale=1.0,maximum-scale=1.0"/><style>body{margin:0px;padding:0px;}iframe{width:100%;height:100%}</style><iframe src="http://www.airtel.in/dot/?dpid=1&dpruleid=3&cat=107&ttl=0&groupname=-&policyname=-&username=-&userip=122.171.125.65&connectionip=127.0.0.1&nsphostname=Policy04-Chennai&protocol=policyprocessor&dplanguage=-&url=http%3a%2f%2fthepiratebay%2eorg%2f" width="100%" height="100%" frameborder=0></iframe>

So it was clear, Airtel was treating CloudFlare just like any other user, and censoring some pages to them. CloudFlare was undergoing a Man-in-the-middle attack by Airtel and didn’t even know it.

Implications

There are some really important conclusions to draw from this.

1. The Pirate Bay has surprisingly chosen not to enforce SSL between CloudFlare and itself, and they talk to each other over HTTP.
2. CloudFlare has chosen to run on an ISP that is censoring traffic upstream and they don’t have mechanisms to detect it, completely defeating the purpose of SSL and providing users (and websites) with a false sense of security. Airtel could modify the response, add tracking codes, etc, and nobody would know.
3. Airtel is sniffing traffic of ALL of CloudFlare’s websites that don’t have Full SSL enabled (which is the default setting on CloudFlare).
4. All Indian users, even if they are not on Airtel’s network, who access any of 2 million+ websites on CloudFlare have their traffic inspected and sniffed by Airtel.

Update 1: According this post by The Register, CloudFlare has acknowledged that this analysis is largely accurate and has claimed that “there are no security flaws on its side”.

Update 2: Airtel’s official response

Our response: Hi Airtel, we understand that the ‘relevant authorities’ demand you block websites, that isn’t in contention. Your response doesn’t address any of the technical points we have raised here. To reiterate, we request you to clarify the following doubts on the matter.

1. Can you confirm how you are implementing the block between CloudFlare and The Pirate Bay?
   From our tests, it appears that you are looking at the ‘Host’ header of every HTTP request on your network, whether from an end user or CloudFlare itself, which is exactly what packet sniffing is.
2. If the above is true, then you are potentially looking at traffic from everyone in India who is accessing a CloudFlare site, irrespective of whether the end user is on Airtel’s network. Can you confirm this?
3. Since you are intercepting and modifying unencrypted requests originating from CloudFlare, you are looking at data that is encrypted over HTTPS between the user and CloudFlare (but not encrypted between CloudFlare and the Origin server), essentially circumventing the purpose of HTTPS entirely. Can you confirm this?

You are free to cross-publish this post on your site, as long as you link back.