China, GitHub and the man-in-the-middle | Hacker News Reader

China, GitHub and the man-in-the-middle

en.greatfire.org

36 pointsmoonboots35 comments

Fwiw, my employer (large East coast USA software firm) also MITMs Github (and the rest of HTTPS, excluding a small whitelist). Their MITM software doesn't even bother to validate the certificates on their side of things, where it is possible. It is … not very awesome.

Is that to discourage employees from working on personal projects at the office, and/or to discourage them from sending company-owned code outside their corporate network?

More the latter. It's probably impossible to stop all encrypted traffic that you can't look at, but you can make it harder for people to do it by stupid or by malware.

OP here. Actually, their logic is that this way they can scan files for viruses (not kidding). (E.g., from gmail attachments.)

This happens at other employers as well; same general rationale.

> and/or to discourage them from sending company-owned code outside their corporate network?

> More the latter

Sooooooo I guess employees have to resort to the old "micro SD card in your shoe" technique...

Or just use a tunneling proxy.

Yes, getting around it is easy. It's just obnoxious, and adds latency, and application support for SOCKS is shitty, and …

I guess I could set up OpenVPN on a VPS or something.

Just curious what the whitelist is... Chrome's pinned certs? That's always a point of curiosity for me: no one knows what Chrome is sending to Google.

Chrome's pinning logic is disabled for connections where the signing cert was added to the trust store by a user, I think largely in part to avoid breaking these type of corporate MITM proxies.

So if you want to watch the traffic, it should be as simple as MITMing yourself with a cert you add to the Chrome trust DB.

I don't want my corp firewall spying on net traffic, so I don't add them to the trusted CAs DB.

It would be slightly more palatable if the firewall did cert validation on the other side of things… but they don't.

No, they MITM google as well as everyone else. The whitelist includes yelp, for some reason... not really sure what else. I definitely do not add their MITM CA as a trusted root in my browser...

This is why calls to make click-throughs for self-signed certificates simpler and less scary are misguided.

Chains of trust can't defend you from this. Only certificate pinning. IMO this shows why self signed is the way to go: There are no authorities you can trust.

Self signed is indistinguishable from "China is MITM'ing you".

We agree about pinning.

As pinning becomes more widespread, browsers that support it will become a sort of surveillance network for forged certificates. That's effectively what caused the Turktrust discovery.

It would be different if it worked like ssh, where key changes are warned about after the (optional) leap of faith.

The SSH model for SSL is a non-starter, because you can MITM bankofamerica.com or Gmail for an hour and find tens of thousands of people who just reinstalled Windows, bought a new iPad, etc etc, and they will fall instantly to your MITM attack. (And -- more's the hilarity -- if they try to go back to bankofamerica.com tomorrow it will look like the bank is trying to MITM them.)

The new ssl pinning proposals work very similarly to ssh. When the user visits an https site with pinning enabled, the browser will remember the server's public key similar to ssh's known_hosts.

You're correct that this won't protect against a MITM during this first visit and will cause confusion if an attacker pins his fraudulent public key. However, I would argue that pinning provides a large net security gain in practice. The same model of vulnerable initial visit but secure subsequent visits is used in HSTS to prevent ssl stripping attacks.

People don't really want self-signed certificates; they just think they want them. When you drill down enough with the "what are you really trying to accomplish here?" questions, people just want a CA that gives them free certs, as many as they like, as often as they like--possibly through an API, even--with no background checks needed, and yet somehow also still protects them from an attacker using exactly the same kind of carefree CA to generate a cert for the same domain. And a pony.

[In other words, people want cert-pinning with a distributed pin cache to prevent initial-session MITM. But they don't know that.]

I have no idea why anyone would have downvoted this; it seems basically accurate.

tl;dr -

"At around 8pm, on January 26, reports appeared on Weibo and Twitter that users in China trying to access GitHub.com were getting warning messages about invalid SSL certificates. The evidence, listed further down in this post, indicates that this was caused by a man-in-the-middle attack."

"The attack happened on a Saturday night. It was very crude, in that the fake certificate was signed by an unknown authority and bound to be detected quickly. The attack stopped after about an hour."

"While the attack was short-lived, it is possible that passwords of many GitHub users were recorded. It’s also possible that the IP addresses of users accessing certain URLs, such as these lists of GFW [Great Firewall] contributors, were tracked."

"HTTPS effectively disables half of what the Great Firewall can do. We have argued for a long time that the reason that Gmail isn’t fully blocked is that it’s considered too important and that the backlash against closing down access would be too great. ... It now appears that GitHub has been added to this list. ... With every website that switches to HTTPS, the authorities’ options are limited to two: completely blocking it, or completely allowing it. The more they fear a public reaction to complete blocks, the fewer their options become. Man-in-the-middle attacks are likely to become increasingly tempting."

"No browser would prevent the authorities from using their ultimate tool though: certificates signed by the China Internet Network Information Center. CNNIC is controlled by the government through the Ministry of Industry and Information Technology. They are recognized by all major browsers as a trusted Certificate Authority. If they sign a fake certificate used in a man-in-the-middle attack, no browser will warn of any usual activity."

> "No browser would prevent the authorities from using their ultimate tool though: certificates signed by the China Internet Network Information Center. CNNIC is controlled by the government through the Ministry of Industry and Information Technology. They are recognized by all major browsers as a trusted Certificate Authority. If they sign a fake certificate used in a man-in-the-middle attack, no browser will warn of any usual activity."

That is the important part. I am surprised China isn't doing this already. Maybe they are doing so, but only for targeted attacks. The CA community really shouldn't grant China any CA authority whatsoever...

You can easily configure your browser to "delete or distrust" the CNNIC's certificates. I just did.

You or I can, sure. But most people don't know how to. And even I use chrome on many machines… should I have to remember to un-trust CNNIC on every single browser I use?

If you're concerned about MITM attacks from China, then yes. But if it actually becomes an issue that most people need to worry about, then a most-people solution will soon be made available (like the browser companies issuing updates that un-trust CNNIC for us).

It's not complicated, anyway. At least in Firefox it's just a menu option in Preferences -> Advanced -> Encryption -> View Certificates.

Maybe your older relatives were already familiar with computers, but, anecdotally, watching my parents, aunts, and grandparents attempt to drive multiple layers of menus … I do not think they could figure out how to un-trust CNNIC (and they wouldn't understand what the impact was, anyway…).

The attack would be easily detectable, and lack any deniability as the use of a CNNIC cert as root is manifest. All in all, it would be a better move for an intelligence agency to take over some marginal Authority in the west and use that for dirty work.

Specifically, I am imagining attacks against political dissidents inside China. Sure, technology savvy folks like us can just un-trust the CNNIC CA. But your average person doesn't know enough to do so.

As long as the Chinese authorities do not use CNNIC ( or whatever other root certificates they could obtain) to mitm SSL connections, they have the ability to escalate attacks. On the other hand, once eavesdropping escalates to this level, it will loose quite quickly all effect. ( Since everyone will then restrict certificates to trusted ones.)

So the Chinese authorities probably save this possibility as a measure of last resort. Instead of encouraging everyone to look for a safer alternative than SSL.

Maybe the goal isn't to monitor their people as much as gain admin access passwords to every major open source project? As talked about prior, backdoors in open source seem like a real concern. Even if source code is public for open source projects, how do we know a precompiled binary actually matches the source?

New findings regarding the Chinese MITM of GitHub.com can be found here: http://netresec.com/?b=1328C6B

Turns out the guy who uploaded the packet capture file was @chenshaoju

Ironically this site gives me an SSL warning about an unknown certificate issuer.

What browser are you using? No issue for me in Chrome.

Firefox 14.0.1 on Ubuntu 12.04.

You can run this to get details about the certificate chain:

    $ SITE=en.greatfire.org
    $ echo "HEAD / HTTP/1.0\n Host: $SITE:443\n\n EOT\n" | openssl s_client -prexit -connect $SITE:443

I'm not sure how to interpret the results, but I'd be thrilled if someone more knowledgeable would comment. I see there is this chain of certs:

    Certificate chain
     0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=greatfire.org
       i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=PositiveSSL CA 2
     1 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
       i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
     2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=PositiveSSL CA 2
       i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root

and openssl seems to complain about a self-signed certificate:

        Verify return code: 19 (self signed certificate in certificate chain)

How do you tell whether it's self signed? There are two certificates so maybe one is not self signed?

Reply on news.ycombinator.com