Live data from Hacker News

Airtel is sniffing and censoring CloudFlare’s traffic in India

medium.com

41–50 of 68 posts

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

#41

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

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

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

#43
post #28
post #20

Earlier quoted context omitted.

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.

TLS transmits the host in cleartext.

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

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

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

#45
post #43
post #28

Earlier quoted context omitted.

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.

TLS transmits the host in cleartext.

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

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

#46
post #44

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.

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

#47

Earlier quoted context omitted.

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 :-)

hah, i was wondering the same :)

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

#48
post #7

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

We give all our customers free certificates for their origin servers. 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.

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

#49
post #43

Earlier quoted context omitted.

TLS transmits the host in cleartext.

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.

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

#50

Earlier quoted context omitted.

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 :-)

For HTTP, yes. There are thousands of other protocols that rely on TLS though.
Post reply on HN