
Airtel is sniffing and censoring CloudFlare’s traffic in India - happyman
https://medium.com/@karthikb351/airtel-is-sniffing-and-censoring-cloudflares-traffic-in-india-and-they-don-t-even-know-it-90935f7f6d98#.df27ssdof
======
spikengineer
Here is what is happening:

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.

~~~
ComodoHacker
>Airtel blocks the http traffic to piratebay

No, Airtel substitutes Piratebay's response to CloudFlare.

~~~
pilif
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.

~~~
apeace
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.

~~~
mikecb
TLS transmits the host in cleartext.

~~~
theandrewbailey
Completely beside the point. Airtel is obviously looking at the HTTP host
header.

~~~
mikecb
Parent suggested deploying TLS from origin to Cloudflare would resolve this.
Simply pointing out that it will not.

~~~
aptwebapps
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.

~~~
astrange
Cloudflare does use SNI to talk to origin servers.

~~~
captn3m0
only if the origin server uses HTTPS and SNI.

------
yoo1I
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".

~~~
jgrahamc
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/)

~~~
r1ch
Why provide the option to use unencrypted origin connections then? If a
customer wants SSL, make them do it right.

~~~
michaelt
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"

~~~
nileshtrivedi
Good example where "false sense of security" can trump "something is better
than nothing".

~~~
taf2
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...

~~~
lmm
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.

------
jakozaur
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/](https://blog.cloudflare.com/cloudflare-ca-encryption-
origin/)

~~~
lmm
> 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.

------
puranjay
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

------
karthikb351
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.

------
hitr
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/](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](https://en.wikipedia.org/wiki/Server_Name_Indication)

~~~
userbinator
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.

~~~
NetStrikeForce
> moving SNI into the encrypted part of the communication.

That's called host header :-)

~~~
stanleydrew
For HTTP, yes. There are thousands of other protocols that rely on TLS though.

~~~
captn3m0
Are there any other protocols that rely on SNI? Genuinely curious.

------
snowy
So is it reasonable to say?: piratebays fault for not enforcing SSL between
their origin servers and cloud flare?

~~~
sneak
Sort of, but the real fault lies with people actively censoring free speech.

TPB could and should mitigate this attack with Origin TLS, yes.

------
ishansharma
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.

------
uber1geek
Airtel is known for doing notorious things in the past. From injecting iframes
to serving compressed images via their own cdn.

------
kekub
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.

------
cesarb
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.

~~~
gnurag
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.

------
runesoerensen
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...](https://support.cloudflare.com/hc/en-
us/articles/200170416-What-do-the-SSL-options-mean-)

[2] [https://www.cloudflare.com/ssl/](https://www.cloudflare.com/ssl/)

~~~
witty_username
Suppose Flexible SSL were disabled and HTTP was used instead; then a malicious
actor can redirect the page
"[http://thepiratebay.com"](http://thepiratebay.com") to
"[https://thepiratebay1.com"](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.

~~~
runesoerensen
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.

------
cvs268
Dear Airtel, sniff this...

[https://pbs.twimg.com/media/CnUlDy0UEAAvTz4.png](https://pbs.twimg.com/media/CnUlDy0UEAAvTz4.png)

------
fahrradflucht
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-know-it-
i-thought-you-meant-airtel-was-quite-confusing-9954b7afc8ac)

~~~
vinothgopi
Yes, the OP mentions in his post itself that all ISP customers get the same
message from Airtel.

~~~
fahrradflucht
Ah so the traffic between piratebay and CloudFlare gets routed through Airtel.
Thanks for pointing that out.

