

China, GitHub and the man-in-the-middle - moonboots
https://en.greatfire.org/blog/2013/jan/china-github-and-man-middle

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

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

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

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

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

~~~
derefr
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.]

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

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

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

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

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

------
dangero
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?

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

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

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

~~~
pjungwir
Firefox 14.0.1 on Ubuntu 12.04.

~~~
pjungwir
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)

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

