Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Airtel is sniffing and censoring CloudFlare’s traffic in India

medium.com

Post reply on HN
Print view View original

31–40 of 68 posts

Re: Airtel is sniffing and censoring CloudFlare’s traffic in India

#31

Post by nileshtrivedi »

michaelt wrote: post #29
r1ch wrote: post #26

Earlier quoted context omitted.

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

Re: Airtel is sniffing and censoring CloudFlare’s traffic in India

#32

Post by regecks »

runesoerensen wrote: post #27

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 i…

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.

Re: Airtel is sniffing and censoring CloudFlare’s traffic in India

#33

Post by mschuster91 »

pilif wrote: post #20
ComodoHacker wrote: post #13

Earlier quoted context omitted.

>Airtel blocks the http traffic to piratebay 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.

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.

Re: Airtel is sniffing and censoring CloudFlare’s traffic in India

#34

Post by [deleted] »

userbinator wrote: post #30
hitr wrote: post #8

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 fo…

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.

[deleted]

Re: Airtel is sniffing and censoring CloudFlare’s traffic in India

#35

Post by NetStrikeForce »

userbinator wrote: post #30
hitr wrote: post #8

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 fo…

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.

> moving SNI into the encrypted part of the communication.

That's called host header :-)

Re: Airtel is sniffing and censoring CloudFlare’s traffic in India

#37

Post by 0xmohit »

spikengineer wrote: post #11

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 se…

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/

Re: Airtel is sniffing and censoring CloudFlare’s traffic in India

#38

Post by taf2 »

nileshtrivedi wrote: post #31
michaelt wrote: post #29

Earlier quoted context omitted.

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

Re: Airtel is sniffing and censoring CloudFlare’s traffic in India

#39

Post by dfox »

userbinator wrote: post #30
hitr wrote: post #8

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 fo…

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.

Moving SNI into the encrypted channel would require completely redesigning TLS's key negotiation mechanism.

Re: Airtel is sniffing and censoring CloudFlare’s traffic in India

#40

Post by lmm »

taf2 wrote: post #38
nileshtrivedi wrote: post #31

Earlier quoted context omitted.

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.

Post reply on HN