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.
Airtel is sniffing and censoring CloudFlare’s traffic in India
61–68 of 68 posts
Re: Airtel is sniffing and censoring CloudFlare’s traffic in India
#62Earlier quoted context omitted.
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.
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.
Re: Airtel is sniffing and censoring CloudFlare’s traffic in India
#63Earlier quoted context omitted.
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.
Cloudflare does use SNI to talk to origin servers.
Re: Airtel is sniffing and censoring CloudFlare’s traffic in India
#64Re: Airtel is sniffing and censoring CloudFlare’s traffic in India
#65All 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/
Re: Airtel is sniffing and censoring CloudFlare’s traffic in India
#66I'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…
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.
Re: Airtel is sniffing and censoring CloudFlare’s traffic in India
#67I'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…
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.
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.
Re: Airtel is sniffing and censoring CloudFlare’s traffic in India
#68Earlier quoted context omitted.
We give all our customers free certificates for their origin servers. http://blog.cloudflare.com/cloudflare-ca-encryption-origin/
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?