Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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


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.


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.


Cloudflare does use SNI to talk to origin servers.


only if the origin server uses HTTPS and SNI.


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.


Yeah, What you said is correct. I was not clear and edited the comment.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: