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 …

COMMENTS

Ummm...

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

Actually...

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

Unencrypted

Facebook

By its nature is a service that splurges all the data you want people to see unencrypted. Hardly a threat to western security to have some poor sods in China having to look through millions of pictures of drunken idiots posing with humourous vegetables and items of road furniture

Protecting users from themselves

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.

There's an add on for Firefox...

HTTPS everywhere

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.

Re: drunken idiots posing with humorous vegetables

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.

More info needed

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

Accential - my arse.

Facinating

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

Here we go again

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.

Scary stuff

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.

Facebook account security settings

Those will be the ones that magically reset themselves to OFF every couple of weeks. You have to keep an eye on the address bar as it's the only indication that you're using the SSL encrypted connection to failbook's servers.

Three who can't be trusted...

fgts don't know 'bout my BGP Traffic-Engineering

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.

Telnet access with no auth

Censorship

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.