Welcome Guest ( Log In | Register )

Outline · [ Standard ] · Linear+

 YouTube Deep Packet Inspection, All HTTP connections being MITMed

views
     
tadwinks
post May 3 2013, 06:00 AM

On my way
****
Senior Member
608 posts

Joined: Jan 2003


QUOTE(klseet @ May 3 2013, 02:35 AM)
Thx Riz for this shocking discovery shocking.gif , never know how dirty these ppl can do out there, at this very sensitive moment ...

Indeed it's blocking on some sensitive videos, I VPNed to SingTel immediately have no problem viewing it.
Regardless what transpired, I believe there should not any such blocking/filtering.

Confirm the following videos can view from SingTel but not in Malaysia, so I just "made" it viewable on my personal site:
http://klseet.com/index.php/news-must-read...the-may13-truth
http://klseet.com/index.php/news-must-read...th-malaysiakini

Hope my site won't be block or kenal tangkap ...
*
Could it be just pure coincidence that TM's uplinks serving those particular 'hot' pages/videos are congested? There could be an inefective balancing/cache algorithm that groups highly sought after content together and is currently congested due to the high viewership demand? And why most local ISPs kena? Because all of them rely on TM's congested connection to get the content, whereas the ISPs that can fetch them are fetching them from Google's other mirrors (maybe HK, SG istead?). This would also explain why VPN-ing, TOR-ing, etc allows the pages to load - client IP changes, redirected to non-TM (and hence non-congested) hosted content. Just an alternate possibility to ISP inteference. It makes no sense to me Maxis, etc would kowtow and put up the blocking (dollars and sense must come first!)
tadwinks
post May 3 2013, 06:53 AM

On my way
****
Senior Member
608 posts

Joined: Jan 2003


QUOTE(wKkaY @ May 3 2013, 06:20 AM)
It is absolutely not a coincidence. The experiments that rizvanrp and I did approached it from two directions:

1) Route requests to the same originating servers, but circumvent packet inspection by splitting HTTP headers across two packets. Requests succeed.

2) Route requests via a intermediate server that has a known good connection with the originating servers. When a packet capture is performed at the intermediate server and at the end-user, we see that packets is sent but not received. Requests still fail.
*
Would splitting requests = smaller request packets? Now just for discussion sake, would a smaller packet somehow be able to 'squeeze' its way in easier? For the second test using a proxy, you saw the reply at the proxy/intermediate server, but its reply to the client was dropped? This is scary because it means that the ISP can filter requests anywhere, and not just at certain waypoints/gateways (and ISP = a majority of Malaysian providers, not just refering to our favourite one). Again, if this censoring is true, I'm sure Google would know about it, and would've surely voiced it out somewhere (unless that's been blocked out too!) Anybody with Google contacts? If this is true, we have to get Google to pull out of Malaysia!

p/s please don't get me wrong, I'm NOT trying to defend anything or anyone here, nor am I a technical expert. I just want the truth, like everybody else. Ubah!
tadwinks
post May 3 2013, 07:24 AM

On my way
****
Senior Member
608 posts

Joined: Jan 2003


QUOTE(rizvanrp @ May 3 2013, 06:59 AM)
*from update 5 on my first post*
...

Hey, here's a simple test you can do with less than 2 commands on a Linux box + Wireshark :

CODE
wget http://www.facebook.com/DAPMalaysia

user posted image

So a HTTP GET request for /DAPMalaysia results in the query taking 109 seconds to respond along with 8 TCP retransmissions (I'm basically getting 0 TCP responses from the server for 109 seconds). Let's see what happens when we request for the exact same URL however we append 1500 bytes of junk URI padding to the end :
Thumbs up! Great stuff. Your latest test have cleared my doubts on the congestion theory. This is gruesomely bad. Please someone with admin contacts to Google/FB/YT get them to shut all pages down as a protest. FOI!!!!

 

Change to:
| Lo-Fi Version
0.0134sec    0.14    6 queries    GZIP Disabled
Time is now: 29th March 2024 - 09:41 AM