Airtel is sniffing and censoring CloudFlare’s traffic in India(medium.com)
medium.com
Airtel is sniffing and censoring CloudFlare’s traffic in India
https://medium.com/@karthikb351/airtel-is-sniffing-and-censoring-cloudflares-traffic-in-india-and-they-don-t-even-know-it-90935f7f6d98#.df27ssdof
67 comments
Funny that this comes from a company that talks of "building a truly transparent network", and says "... And we have nothing to hide."
https://www.airtel.in/opennetwork/
https://www.airtel.in/opennetwork/
Well, they are being transparent. Courts ordered them to block Pirate Bay, so they complied and put up a notice saying so.
in my opinion transparency is something of a red herring, or buzzword.
usually you can tell what's going on inside of an organization just by observing what they do.
conversely, if you can't observe it, how would you know they're not being transparent (despite their claims)?
usually you can tell what's going on inside of an organization just by observing what they do.
conversely, if you can't observe it, how would you know they're not being transparent (despite their claims)?
court usually asks to block URLs, not to sniff data between PirateBay and CloudFlare.
And how would you block url without sniffing packets?
>Airtel blocks the http traffic to piratebay
No, Airtel substitutes Piratebay's response to CloudFlare.
No, Airtel substitutes Piratebay's response to CloudFlare.
And this is why we want HTTPS everywhere. Yes. It would probably mean that the site is completely not reachable, but I prefer that to an altered response.
Unless I'm mistaken, the site could be made reachable if only TPB would enable SSL between Cloudflare and their origin.
Currently, Airtel is blocking based on the Host header. If they can't see the Host header, they'd have to instead know TPB's origin IP, which they wouldn't.
Currently, Airtel is blocking based on the Host header. If they can't see the Host header, they'd have to instead know TPB's origin IP, which they wouldn't.
TLS transmits the host in cleartext.
[deleted]
Completely beside the point. Airtel is obviously looking at the HTTP host header.
Parent suggested deploying TLS from origin to Cloudflare would resolve this. Simply pointing out that it will not.
The post said that Cloudfare communicates with TPB via its IP address, not its host name, and that Airtel must be sniffing the hostname out of the header. So if they went full TLS Airtel would have to block the relevant IPs, which can be a little harder to find out, instead of the host.
Most layer 7 blocking mechanisms look for the SNI header in a TLS datagram or the host header. It's not complicated and trivial to do. Only looking at the host header would be quite amateurish. I'm not a security expert, and even I know this.
CF could use some sort of IPSec or SSL tunnel back to another datacenter to make the origin request. It would add a lot of latency, but it would ensure that local authorities don't mess with the traffic. This was a popular way for CDN's to get around China for a while. I believe one CDN provider billed it as "Secure origin routing." I doubt that they still offer it, as everyone wants to play ball and make money in the end.
CF could use some sort of IPSec or SSL tunnel back to another datacenter to make the origin request. It would add a lot of latency, but it would ensure that local authorities don't mess with the traffic. This was a popular way for CDN's to get around China for a while. I believe one CDN provider billed it as "Secure origin routing." I doubt that they still offer it, as everyone wants to play ball and make money in the end.
It is still possible, it needs three things to work:
1) SNI indicators on the HTTPS handshake deliver the hostname to the DPI processor, be it on the connection Consumer => CF or CF => TPB.
2) Most likely the provider has a trusted CA... and CF => TPB connection does not support pinning.
3) Provider redirects to interceptor, which serves a "blocked" notice page, with a trusted HTTPS cert.
Alternative to 2 & 3 in case provider doesn't want to risk his CA: simply drop the connection by injecting a FIN packet once TPB is seen in the SNI headers.
1) SNI indicators on the HTTPS handshake deliver the hostname to the DPI processor, be it on the connection Consumer => CF or CF => TPB.
2) Most likely the provider has a trusted CA... and CF => TPB connection does not support pinning.
3) Provider redirects to interceptor, which serves a "blocked" notice page, with a trusted HTTPS cert.
Alternative to 2 & 3 in case provider doesn't want to risk his CA: simply drop the connection by injecting a FIN packet once TPB is seen in the SNI headers.
Yeah, What you said is correct. I was not clear and edited the comment.
All I'm hearing is that Cloudflare allows their customers to configure client facing TLS without enforcing it upstream over the internet, providing a false sense of security. Thanks Cloudflare!
... and I'm pretty sure that their response will be "We are just a proxy, we are not responsible for anything".
... and I'm pretty sure that their response will be "We are just a proxy, we are not responsible for anything".
We give all our customers free certificates for their origin servers.
http://blog.cloudflare.com/cloudflare-ca-encryption-origin/
http://blog.cloudflare.com/cloudflare-ca-encryption-origin/
@jgrahamc: Do you think it would be feasible to add clearer notification about potentially creating a false sense of security to the Cloudflare ui, when no origin SSL is present? What Cloudflare calls "Flexible SSL" has real implications and I think one of the necessary evils of infosec work is pushing people towards more informed decision making.
As a frequent Cloudflare freeloader and occasional paying customer (lots of different hats), I really appreciate how the service made it possible to use SSL for free, before it was cool.
With Let's Encrypt being implemented at a lot of hosting providers and hosting automation systems over time, I think the following may become a diminishing problem.
But in cases where, let's say, a "not top tier" hosting solution makes it impossible to use any sort of SSL/TLS back to the origin server (within the customer's budget), my personal choice has been to not defaulting/redirecting sites to Cloudflare's SSL.
And I mean, it's not like crappy hosting without Let's Encrypt automation or the ability to add Cloudflare's origin CA, is going away. One of Cloudflare's selling points at the low end, is how the service stretches the capabilities and resources of less than optimal hosting and apps. I mean, the idea of running Wordpress without Cloudflare or a similar service in front, really gives me the heebie jeebies.
Not going half-way with SSL is sort of an ethical choice for me, exactly for the reason of not wanting to give a false sense of security, even at the cost of Google juice.
I'm technically proficient enough to understand that client -> Cloudflare https connections can stop a lot of ISP/last mile/LAN level tracking and code injection, though. And obvioulsy, Cloudflare is a MiTM. So it's a real choice with tradeoffs.
But I work at a grass-roots level where I usually am the only person tangible IT skills. When it comes down to it, I feel quite strongly that we should avoid messing with people's already vague understanding of what that "green lock" means.
As a frequent Cloudflare freeloader and occasional paying customer (lots of different hats), I really appreciate how the service made it possible to use SSL for free, before it was cool.
With Let's Encrypt being implemented at a lot of hosting providers and hosting automation systems over time, I think the following may become a diminishing problem.
But in cases where, let's say, a "not top tier" hosting solution makes it impossible to use any sort of SSL/TLS back to the origin server (within the customer's budget), my personal choice has been to not defaulting/redirecting sites to Cloudflare's SSL.
And I mean, it's not like crappy hosting without Let's Encrypt automation or the ability to add Cloudflare's origin CA, is going away. One of Cloudflare's selling points at the low end, is how the service stretches the capabilities and resources of less than optimal hosting and apps. I mean, the idea of running Wordpress without Cloudflare or a similar service in front, really gives me the heebie jeebies.
Not going half-way with SSL is sort of an ethical choice for me, exactly for the reason of not wanting to give a false sense of security, even at the cost of Google juice.
I'm technically proficient enough to understand that client -> Cloudflare https connections can stop a lot of ISP/last mile/LAN level tracking and code injection, though. And obvioulsy, Cloudflare is a MiTM. So it's a real choice with tradeoffs.
But I work at a grass-roots level where I usually am the only person tangible IT skills. When it comes down to it, I feel quite strongly that we should avoid messing with people's already vague understanding of what that "green lock" means.
Can you pass down a header to the client describing the security of the origin connection? Or let me pass CloudFlare a header that I explicitly would rather you drop the connection than plain text it back to origin?
I like the idea of a client-specified HSTS header - allowing users to control their risk directly (albeit through a browser extension) would definitely be a good thing.
Why provide the option to use unencrypted origin connections then? If a customer wants SSL, make them do it right.
Presumably because some people have backends that don't support SSL (e.g. anything hosted on S3) and CloudFlare thought "eh, some encryption is better than nothing, and they're going to let us MITM their encrypted connection anyway so they're obviously not a bank or something really important"
Good example where "false sense of security" can trump "something is better than nothing".
it still is providing more security. yes it has a security hole, but for example if i'm in starbucks - you can't sniff out my cookies over the ssl encrypted traffic. Sure a backend provider can, but it's a layer of protection... I suppose an interesting question here is there away for the browser client to detect this type of hole and alert end users to the risk...
No, it's fundamentally impossible - as far as the browser is concerned it's talking to a server that's speaking HTTPS (CloudFlare's server) and it can't possibly know what that server's doing behind the scenes.
If I see HTTPS in the title bar I expect the owner of that certificate to be responsible for the content I'm seeing. It's utterly irresponsible of CloudFlare to enable this kind of configuration.
If I see HTTPS in the title bar I expect the owner of that certificate to be responsible for the content I'm seeing. It's utterly irresponsible of CloudFlare to enable this kind of configuration.
The threat is completely different, although I agree with you they're providing the illusion of end to end security when that's not the case.
The likelihood of a bad actor between Cloudflare and the origin server seems lower than a bad actor between Cloudflare and the user - where I'd class a coffee shop wifi portal page as a bad actor.
The likelihood of a bad actor between Cloudflare and the origin server seems lower than a bad actor between Cloudflare and the user - where I'd class a coffee shop wifi portal page as a bad actor.
Yeah, it's intrinsic of how the flexible ssl option works: https://support.cloudflare.com/hc/en-us/articles/200170416-W...
I see a lot of people bashing CloudFlare, but to be fair:
1. Thanks to them many sites got SSL and sniffing your local network/ISP is source of majority of the problems.
2. Some SSL is better than no SSL, though it can also create illusion of full security.
3. You can configure encryption between CloudFlare and your origin. You probably should do that.
4. CloudFlare this year (May 2016) announce better tooling to encrypt between origin and their own CDN servers: https://blog.cloudflare.com/cloudflare-ca-encryption-origin/
1. Thanks to them many sites got SSL and sniffing your local network/ISP is source of majority of the problems.
2. Some SSL is better than no SSL, though it can also create illusion of full security.
3. You can configure encryption between CloudFlare and your origin. You probably should do that.
4. CloudFlare this year (May 2016) announce better tooling to encrypt between origin and their own CDN servers: https://blog.cloudflare.com/cloudflare-ca-encryption-origin/
> 2. Some SSL is better than no SSL, though it can also create illusion of full security.
In this scenario the illusion is a much bigger problem than the benefits. If I make a request over https I do not expect my traffic to be sent unencrypted over the open internet.
In this scenario the illusion is a much bigger problem than the benefits. If I make a request over https I do not expect my traffic to be sent unencrypted over the open internet.
Or you could get a let's encrypt certificate and have actual security for free.
Not just "an Indian ISP". It's the largest ISP in the country, and one with an increasingly larger footprint in Africa. It had revenues of close to $15B last year
Hi, OP here.
There are basically two important points from this story.
> CF can't tell if it's the actual website or the notice from Airtel, and neither can the user.
> Airtel is implementing this block by looking at the Host: headers of ALL HTTP requests going out of CF, and since everyone in India will hit CF, they are now looking at the headers of all users in India, across ISPs.
There are basically two important points from this story.
> CF can't tell if it's the actual website or the notice from Airtel, and neither can the user.
> Airtel is implementing this block by looking at the Host: headers of ALL HTTP requests going out of CF, and since everyone in India will hit CF, they are now looking at the headers of all users in India, across ISPs.
In the article,testing the host header with different IP is done over http and not https.so i so it does not prove that Airtel is sniffing https traffic,isn't it ?
>curl -H "Host: thepiratebay.org" http://192.30.253.112/
May be I missed something. Technically it is possible block the traffic by looking at SNI[1] or simply block the ipaddress if it belongs to the blocked site.I always thought that every ISPs had to follow this because all ISPS are asked to block a list of such sites by the Supreme Court .
[]1 https://en.wikipedia.org/wiki/Server_Name_Indication
>curl -H "Host: thepiratebay.org" http://192.30.253.112/
May be I missed something. Technically it is possible block the traffic by looking at SNI[1] or simply block the ipaddress if it belongs to the blocked site.I always thought that every ISPs had to follow this because all ISPS are asked to block a list of such sites by the Supreme Court .
[]1 https://en.wikipedia.org/wiki/Server_Name_Indication
It is possible for them to block the access to such a site using SNI, however they will not be able to do a man-in-the-middle attack (as it would be possible in this scenario) unless they could obtain a valid certificate for the site.
It can't sniff https traffic, except for basic metadata.
The point is that many sites using cloudflare talk to cloudflare over HTTP (while users get HTTPS), and airtel is sniffing that.
The point is that many sites using cloudflare talk to cloudflare over HTTP (while users get HTTPS), and airtel is sniffing that.
I wonder if there's any proposals/extensions for moving SNI into the encrypted part of the communication. The initial certificate would have to be keyed to the IP address of the server, or maybe something from DNS, and probably there are other complications too, but it'd at least reduce the amount of plaintext information transmitted with each connection.
This has been discussed ad nauseum on the TLS-WG mailing list. Just search for "encrypted SNI". Or click here for ekr's initial email: https://www.ietf.org/mail-archive/web/tls/current/msg18633.h....
[deleted]
Moving SNI into the encrypted channel would require completely redesigning TLS's key negotiation mechanism.
The server wouldn't know which key to use to decrypt the rest of the message.
> moving SNI into the encrypted part of the communication.
That's called host header :-)
That's called host header :-)
For HTTP, yes. There are thousands of other protocols that rely on TLS though.
Are there any other protocols that rely on SNI? Genuinely curious.
hah, i was wondering the same :)
I know I'm being a bit cynical here but do we know that Cloudflare doesn't know about it?
It's entirely possible that they know about it. Considering their recent datacenter opening in India (again, not clear on laws but maybe they need to follow the blocking as ordered by DoT/courts?)
They just started operations in China and partnered with an ISP there, so unless they say that they are not involved, I'm sceptical about this.
It's entirely possible that they know about it. Considering their recent datacenter opening in India (again, not clear on laws but maybe they need to follow the blocking as ordered by DoT/courts?)
They just started operations in China and partnered with an ISP there, so unless they say that they are not involved, I'm sceptical about this.
Airtel is known for doing notorious things in the past. From injecting iframes to serving compressed images via their own cdn.
Is there any way for cloudflare to detect wether or not their connection has been modified by a third party besides certificates? I could only think of loading the site from more than one location and comparing the responses. However that might not be a trivial task, as most websites will not be static enough.
In cases like this, where the upstream of some of Cloudflare's servers is known to be non-transparent (dropping or modifying data going through it), couldn't they tunnel everything to Cloudflare servers with a working upstream, and connect to the origin servers from there? They would still benefit from caching near the users, while avoiding the broken upstream.
The lesson learnt from this fiasco is that CF can't trust its upstream ISPs, so tunneling traffic over to another ISP in a different geo adds additional overhead without actually solving the problem.
The right approach to fix upstream MITM is to drop http+https mix and match mode.
The right approach to fix upstream MITM is to drop http+https mix and match mode.
I've never understood CloudFlare's position on this issue/feature. They generally do a great job at improving, caring and fighting for internet security, yet continue to offer a product (Flexible SSL) that they know is insecure:
This option is not recommended if you have any sensitive information on your website. It should only be used as a last resort if you are not able to setup SSL on your own web server, but it is less secure than any other option (even “Off”) [1]
So by CF's own admission this is less secure than having SSL disabled. That's of course technically incorrect assuming the visitor is aware that SSL is terminated at CloudFlare, and insecure from there to the origin server. If the visitor is aware of this distinction (and know what it means, which includes knowing where the CF edge and origins are located) then it does add some security (the coffeeshop's Wi-Fi etc).
However it's probably fair to assume that most visitors of CloudFlare-protected sites are not aware of this distinction. They're probably just aware that Green Lock + HTTPS = secure. So instead this product primarily gives a visitor a false sense of security, which in my opinion is much worse and potentially dangerous. I guess CloudFlare agrees with that; why else would they say it's less secure than no SSL?
In the end, CloudFlare should clarify why they continue to offer a seemingly secure encryption product that they themselves consider less secure than no encryption. They say it should only be used "as a last resort", but when is choosing "Flexible SSL" really the last resort? I mean, you can just disable SSL entirely or do it properly (and even get a free certificate from CF), both of which are more secure.
I don't know, but here's an idea: It might be a good product for CloudFlare customers, such as TBP, who don't care enough to actually secure their visitors' traffic, but still want to give the appearance thereof. Which is exactly what the more prominent product page lists as the advantages of "Flexible SSL"[2]:
- You do not need an SSL certificate on your server.
- Visitors will see the SSL lock icon in their browser.
I might be missing something and I'd honestly appreciate if someone can shed some light on this. I respect CloudFlare a lot and appreciate their efforts to improve internet security. It's just difficult to maintain a brand as a company on the forefront of the internet security battle, while also enabling customers to somewhat deceitfully give the appearance of security at the expense of their visitors' security and safety. It seems pretty clear that CF needs to discontinue this product before it hurt their brand as well as unassuming visitors.
[1] https://support.cloudflare.com/hc/en-us/articles/200170416-W...
[2] https://www.cloudflare.com/ssl/
This option is not recommended if you have any sensitive information on your website. It should only be used as a last resort if you are not able to setup SSL on your own web server, but it is less secure than any other option (even “Off”) [1]
So by CF's own admission this is less secure than having SSL disabled. That's of course technically incorrect assuming the visitor is aware that SSL is terminated at CloudFlare, and insecure from there to the origin server. If the visitor is aware of this distinction (and know what it means, which includes knowing where the CF edge and origins are located) then it does add some security (the coffeeshop's Wi-Fi etc).
However it's probably fair to assume that most visitors of CloudFlare-protected sites are not aware of this distinction. They're probably just aware that Green Lock + HTTPS = secure. So instead this product primarily gives a visitor a false sense of security, which in my opinion is much worse and potentially dangerous. I guess CloudFlare agrees with that; why else would they say it's less secure than no SSL?
In the end, CloudFlare should clarify why they continue to offer a seemingly secure encryption product that they themselves consider less secure than no encryption. They say it should only be used "as a last resort", but when is choosing "Flexible SSL" really the last resort? I mean, you can just disable SSL entirely or do it properly (and even get a free certificate from CF), both of which are more secure.
I don't know, but here's an idea: It might be a good product for CloudFlare customers, such as TBP, who don't care enough to actually secure their visitors' traffic, but still want to give the appearance thereof. Which is exactly what the more prominent product page lists as the advantages of "Flexible SSL"[2]:
- You do not need an SSL certificate on your server.
- Visitors will see the SSL lock icon in their browser.
I might be missing something and I'd honestly appreciate if someone can shed some light on this. I respect CloudFlare a lot and appreciate their efforts to improve internet security. It's just difficult to maintain a brand as a company on the forefront of the internet security battle, while also enabling customers to somewhat deceitfully give the appearance of security at the expense of their visitors' security and safety. It seems pretty clear that CF needs to discontinue this product before it hurt their brand as well as unassuming visitors.
[1] https://support.cloudflare.com/hc/en-us/articles/200170416-W...
[2] https://www.cloudflare.com/ssl/
Yup, I have never seen a straight answer to this concern.
One one hand, it seriously undermines the meaning of the browser padlock.
On the other hand, this has already been happening in less visible ways - Cloudflare is definitely not the first to do this. Plenty of sites and services terminate SSL early (and plenty of public CDNs offer edge SSL). The idea of end-to-end transport security via TLS is a bit flimsy to begin with tbh.
What I find disappointing is that it encourages the "checklist security" approach. Management/dev/ops sees that this is the simplest way to get the padlock to show up, and the story ends there.
One one hand, it seriously undermines the meaning of the browser padlock.
On the other hand, this has already been happening in less visible ways - Cloudflare is definitely not the first to do this. Plenty of sites and services terminate SSL early (and plenty of public CDNs offer edge SSL). The idea of end-to-end transport security via TLS is a bit flimsy to begin with tbh.
What I find disappointing is that it encourages the "checklist security" approach. Management/dev/ops sees that this is the simplest way to get the padlock to show up, and the story ends there.
Suppose Flexible SSL were disabled and HTTP was used instead; then a malicious actor can redirect the page "http://thepiratebay.com" to "https://thepiratebay1.com". Thus HTTPS (encryption) is there, but it isn't The Pirate Bay (authentication is not there). So, Flexible SSL is still better than HTTP, at least you're protected from your coffee shop.
[deleted]
I agree that it's somewhat technically more secure in that it prevents a wide array of attack vectors.
Despite of that my point is that, for the vast majority of visitors, the solution ends up being less secure due to imperfect information; If you access a service over HTTP you can accurately asses the (lack of) security and, based on an informed assessment of the risks, decide wether you want to proceed.
If you access a site over a seemingly secure connection that is terminated prior to reaching the origin, then you most likely don't have the necessary information to assess the security and associated risks relative to what you're doing: Your browser is telling you that you're at the right domain and that the connection is secure with modern cryptography (if the site is using CloudFlare). However that's not the entire story.
The browser is not telling you that the secure connection is terminated at the CloudFlare edge. This leaves it to the CloudFlare-protected site to inform the visitor that the connection is only secure some of the way in order for the visitor to make an accurate assessment of the connection's security.
I don't think most CF customers who pick "Flexible SSL" are thoroughly and accurately informing visitors of these nuances (and even if they are an MITM can modify it). That's why I absolutely do not think it's better than HTTP -- exactly because of the problems outlined in this article.
In this case I'd argue that, from the perspective of a TBP visitor, "Flexible SSL" improves security on less relevant vectors while significantly decreasing security on the vectors that matter. The coffee shop owner probably doesn't care that much about the IP rights of H/Bollywood, but this is the attack vector that Flexible SSL helps mitigate. The government does however care about such rights and CloudFlare's ISP was forced/willing to help them. CFs solution did nothing to mitigate this vector.
Now I'm not saying this is all CloudFlare fault, but I do think they share a part of the responsibility. TBP's recklessness has allowed millions of people around the world to access and use their site under the false assumption that they were protected. What I don't get is why CloudFlare has any interest in enabling such behavior. They know full well the risks associated with this solution and even admit it's inferiority compared to commando-style unencrypted HTTP. It also decreases my trust in other CloudFlare-protected sites - for all I know, as a visitor, the site may or may not be using Flexible (or perhaps just "Broken") SSL.
My suggestion is simply that they use their knowledge to provide a better service to their customers and their visitors. That probably means discontinuing this product - or clarify why the don't think that's necessary.
Despite of that my point is that, for the vast majority of visitors, the solution ends up being less secure due to imperfect information; If you access a service over HTTP you can accurately asses the (lack of) security and, based on an informed assessment of the risks, decide wether you want to proceed.
If you access a site over a seemingly secure connection that is terminated prior to reaching the origin, then you most likely don't have the necessary information to assess the security and associated risks relative to what you're doing: Your browser is telling you that you're at the right domain and that the connection is secure with modern cryptography (if the site is using CloudFlare). However that's not the entire story.
The browser is not telling you that the secure connection is terminated at the CloudFlare edge. This leaves it to the CloudFlare-protected site to inform the visitor that the connection is only secure some of the way in order for the visitor to make an accurate assessment of the connection's security.
I don't think most CF customers who pick "Flexible SSL" are thoroughly and accurately informing visitors of these nuances (and even if they are an MITM can modify it). That's why I absolutely do not think it's better than HTTP -- exactly because of the problems outlined in this article.
In this case I'd argue that, from the perspective of a TBP visitor, "Flexible SSL" improves security on less relevant vectors while significantly decreasing security on the vectors that matter. The coffee shop owner probably doesn't care that much about the IP rights of H/Bollywood, but this is the attack vector that Flexible SSL helps mitigate. The government does however care about such rights and CloudFlare's ISP was forced/willing to help them. CFs solution did nothing to mitigate this vector.
Now I'm not saying this is all CloudFlare fault, but I do think they share a part of the responsibility. TBP's recklessness has allowed millions of people around the world to access and use their site under the false assumption that they were protected. What I don't get is why CloudFlare has any interest in enabling such behavior. They know full well the risks associated with this solution and even admit it's inferiority compared to commando-style unencrypted HTTP. It also decreases my trust in other CloudFlare-protected sites - for all I know, as a visitor, the site may or may not be using Flexible (or perhaps just "Broken") SSL.
My suggestion is simply that they use their knowledge to provide a better service to their customers and their visitors. That probably means discontinuing this product - or clarify why the don't think that's necessary.
[deleted]
[deleted]
Dear Airtel, sniff this...
https://pbs.twimg.com/media/CnUlDy0UEAAvTz4.png
https://pbs.twimg.com/media/CnUlDy0UEAAvTz4.png
Seems like it's not just airtel:
https://medium.com/@sushubh/when-you-said-they-do-not-even-k...
https://medium.com/@sushubh/when-you-said-they-do-not-even-k...
Yes, the OP mentions in his post itself that all ISP customers get the same message from Airtel.
Ah so the traffic between piratebay and CloudFlare gets routed through Airtel. Thanks for pointing that out.
It's only airtel blocking the connection between Cloudflare India's servers and the Origin server's for piratebay because Cloudflare uses Airtel as it's ISP for it's datacentres.
Cloudflare Indian datacentres are hosted on Airtel's networks.
Airtel by default blocks and replaces(with a notice) Piratebay traffic all across it's network due to multiple court orders.
Cloudflare India servers call the piratebay origin servers and ask for a master copy and Airtel instead gives the substitute page on all the http traffic from piratebay to cloudflare servers.
Cloudflare servers display the malformed page they received from Airtel to all clients(all ISP's) asking for piratebay in India.