Facebook traffic mysteriously passes through Chinese ISP For a short time on Tuesday, internet traffic sent between Facebook and subscribers to AT&T's internet service passed through hardware belonging to the state-owned China Telecom before reaching its final destination, a security researcher said. An innocent routing error is the most likely explanation for the highly circuitous …
"Lyon said he has no evidence any data was in fact snarfed"...
Well of course there isn't any evidence, China Telecom are hardly likely to tell you and unless you're using quantum encryption you can't tell if things have been looked at or copied before they reach their destination.
Hopefully it was just an accidental routing glitch, and not a deliberately configured Chinese router offering a faked 1 hop to final destination to any US router which cared to listen.
Chinese helicopters obviously.
... I hope it was the Chinese being naughty. Otherwise it means that we're a long, long way from having any form of determinism in our comms. With this sort of thing going on I assume US traffic could one day be dutifully recorded by Brit ISPs, ready for GCHQ to have a good peek, for example. Mind you, it may be the only way to get free information out of our allies.
If this was a routing error then presumably all the encrypted traffic went through the Chinese ISP as well. So ...
Set your filter to drop all the unencrypted data on the floor. There's almost certainly nothing of interest in there. Then capture all the encrypted connections and start looking for IP addresses of "people of interest". You don't know what they are saying, but if they live locally then perhaps you can use some rubber hose cryptography on them.
There's really no IT angle to this story. It's just a normal day in the life of a brutal dictatorship.
You have to remember that not everyone knows what HTTPS really means, let alone that their data can be redirected to another ISP, rogue or otherwise. I'd hazard a guess at saying a large majority of those who do have at least some clue about HTTPS think it's to protect them in public/open wifi hotspots, libraries etc.
This post has been deleted by its author
I'm running this plugin from my home PC and it generally works quite well. In practice I had to make exceptions for one or 2 services, including Facebook, due to slower than acceptable performance over HTTPS. Adding exceptions to HTTPS everwhere reverts the connection to the unencrypted plain HTTP version of the service.
Still better to encrypt opportunistically when you can, same reason I prefer envelopes over postcards for snail mail.
Does this type of incident only get reported when the route takes the traffic through China? Or is it really as it seems that every time there is a routing issue of this nature the traffic ends up in China?
Clearly there is big difference in implications between the two scenarios...
So, in other words ATT cannot be bothered to filter routes from China Telecom according to their declared address ranges in ARIN, RIPE and APNIC. Textbook example of "how not to run an ISP".
It is also a good illustration of one of the key differences between US Internet vs EU Internet.
In EU most peering is public and ISPs either filter announcements themselves or rely on the peering point routeserver to do so. As a result the chance of someone hijacking traffic that does not belong to them is pretty slim. This means that they have to add those ranges to their policy in RIPE, the ISPs have to pick that up and the filters have to be changed accordingly. The chance of this happening unnoticed is pretty slim.
In the US most peering is private and route announcements are unfiltered. As a result a "rogue" ISP can hijack traffic at will. IMO in this particular case the classic "never attribute to malice what you can attribute to sheer incompetence" probably needs to be reversed. One time may be incompetence. Doing it regularly is something else.
Epic FAIL. As an appropriate label for ATT peering policy manager.
I was working a largely ATT outage yesterday in the US, in which developed quite large packet loss and latency. Some US ATT home customers were being routed (with a lot of packet loss) via China Telecom US addresses (accessible via whois, CT don't believe in DNS records). Other traceroutes went via what looked like ATT addresses. Must revisit some of those traceroutes.....
As we all know, Facebook is used in China and abroad by dissidents and as a secure means of transmitting sensitive information. Every day, millions of Chinese Facebook users transmit their Falungong membership lists to the Dalai Lama's page.
Even more likely is it that big brother is trying to find out what your Farm is producing, as Comrade Wen brings his two year quest for domination of Facebook games.
Next we will learn that The Register is available in China.
it is.
For example see the pages used by the Egyptian protesters during the recent events. Even old documents that were stored in the ministry of information, started appearing there wikileaks-style.
Other examples I know of include the failed protests in Angola (failed after the gov took control before it went any further)
Why people do this is another question. Sheer incompetence by the protesters, or some higher malice? I'll let you decide.
This post has been deleted by its author
With the amount of bugs still plaguing networking hardware there's not need for all that trouble.
Maybe a more plausible idea is that some routers were hacked into? I really doubt AT&T would come out in public to confirm their kit was vulnerable, better to portray it as an isolated accident.
I peer with AS4134. I prefer his China routes because they are directly connected. So, I set BGP LOCAL-PREF on them over all other points where I might see them. I am ATT peering co-ordinator (except I am not in this case).
In the meantime, China Telecom, AS4134, just like any other provider are also peering with facebook and taking AIDS in at all IXPs. They make a change to their peering prefix-list/ communities/ as-path regular expressions and - suddenly AIDS is announced via China to ATT. ATT now has the AIDS and forwards traffic in that direction.
It's a simple configuration step for the BGP Peering co-ordinator in AS4134 to get his config wrong and release the AIDS toward ATT.
And so traffic flows toward AIDSBook exiting the ATT autonomous system via China Telecom because ATT Policy says so.
It's a problem in China that can be used to exploit traffic flows but it is open to any ISP that does not filter properly. The internet is stuck together with glue and tape.
Behind AS4134 there is a very powerful network but this is nothing more than a BGP Traffic-Engineering issue that goes on daily.
While the Great Wall does exist, it has more holes than Granny's knickers.
Attempts from inside mainland China to use a certain search engine were blocked. Attempts to its home in another country were not blocked.
Also, blockages seem to vary depending on region. In Shenzhen, at a hotel for business travellers from the west, there was pretty much nothing blocked. At a resort in Hainan (darn sarf, their version of Hawaii), pretty much everything was blocked and needed minor cunningness to get at it.
Facebook? I could do with a week without it.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
