New clamping down on information in China

Spotted this on a net security research blog yesterday: someone is trying to snoop on the web traffic of Chinese students and researchers:

All evidence indicates that a MITM [man-in-the-middle] attack is being conducted against traffic between China’s nationwide education and research network CERNET and www.google.com. It looks as if the MITM is carried out on a network belonging to AS23911, which is the outer part of CERNET that peers with all external networks. This network is located in China, so we can conclude that the MITM was being done within the country.

To decipher this, readers should note that CERNET is the Chinese network for education and research - universities and the like. The regular Great Firewall of China blocking is fairly crude and makes it practically difficult for researchers to get access to the information they need, so CERNET users have mostly free access to the Internet at large - I'm sure their universities block access to dodgy sites, but to be fair so do Western universities. What's happening is that someone is intercepting - not just snooping on - their requests to go to www.google.com and is trying to pretend to be Google.

The reason the intercept is failing is because Google - like Facebook, Yahoo, Twitter and other sites - redirects plain HTTP requests to its homepage to a HTTPS address, so most people bookmark those sites with an HTTPS address. Therefore the users were requesting https://www.google.com/ and the attackers had to fake Google's SSL certificate. Because of of the way SSL is designed, this is quite hard; they couldn't get a reputable Certificate Authority to sign their certificate saying "sure, this is Google" so they signed it themselves, much like a schoolchild signing a note purportedly from their parent but with their own name. Modern browsers (Chrome, Firefox, modern versions of IE) warn you when this is happening, which is how the users noticed. The Netresec team's analysis showed that the timings of the steps of the connection indicated strongly that the interceptor was somewhere within China.

The attack doesn't seem to be very sophisticated, but it does require reasonable resources and access to networking systems - you've got to reprogram routers in the path of the traffic to redirect the traffic going to Google to come to your own server instead, so you either need to own the routers to start with or compromise the routers of an organisation like a university. Generally, the further you get from the user you're intercepting, the greater your resources need to be. It would be interesting to know what fraction of traffic is being intercepted - the more users you're intercepting, the more computing resource you need to perform the attack because you've got to intercept the connection, log it, and then connect to Google/Twitter/Yahoo yourself to get the results the user is asking for.

The attempted intercepts were originally reported on the Greatfire.org blog which observes that there were several reports from around CERNET of this happening. Was this a trial run? If so it has rather blown up in the faces of the attackers; now the word will circulate about the eavesdropping and CERNET users will be more cautious when faced with odd connection errors.

If the attackers want to press on, I'd expect the next step to be more sophisticated. One approach would be SSL stripping where the interceptor tries to downgrade the connection - the user requests https://www.twitter.com/ but the attacker rewrites that request to be http://www.twitter.com/. The user's browser sees a response for http instead of https and continues with an unencrypted connection. Luckily, with Twitter this will not work well. If you run "curl -I https://www.twitter.com/" from a command line, you'll see this:

HTTP/1.1 301 Moved Permanently
content-length: 0
date: Sat, 06 Sep 2014 17:23:21 UTC
location: https://twitter.com/
server: tsa_a
set-cookie: guest_id=XXXXXXXXXXXXXXXXX; Domain=.twitter.com; Path=/; Expires=Mon, 05-Sep-2016 17:23:21 UTC
strict-transport-security: max-age=631138519
x-connection-hash: aaaaaaaaaaaaaaaa

That "strict-transport-security" line tells the browser that future connections to this site for the next N seconds must use HTTPS, and the browser should not continue the connection if the site tries to use HTTP. This is HTTP Strict Transport Security (HSTS) and Twitter is one of the first big sites I've seen using it - Google and Facebook haven't adopted it yet, at least for their main sites.

Alternatively the interceptor may try to compromise a reputable certificate authority so it can forge SSL certificates that browsers will actually accept. This would be a really big investment, almost certainly requiring nation-state-level resources, and would probably not be done just to snoop on researchers - if you can do this, it's very valuable for all sorts of access. It also won't work for the major sites as browsers like Chrome and Firefox use certificate pinning - they know what the current version of those sites' SSL certs look like, and will complain loudly if they see something different.

The most effective approach, for what it's worth, is to put logging software on all the computers connected to CERNET, but that's probably logistically infeasible - it only works for targeting a small number of users.

So someone with significant resources in China is trying to find out what their researchers are searching for. Is the government getting nervous about what information is flowing into China via this route?