
Github SSL replaced by self-signed certificate in China - teawithcarl
CHINA NEWS -<p>Man-in-the-middle attack on Github. -- http://bit.ly/Vqh8zJ <p>Fake GITHUB cert -- http://www.mediafire.com/?zx6eno648axz7bh<p>Twitter (Github attack news) -- https://www.twitter.com/search/?q=Github%20SSL
======
agl
Firstly, thanks to GitHub using HSTS on github.com (although not
www.github.com), the certificate error will be fatal in Chrome and (I believe,
but haven't checked) Firefox as long as you have visited GitHub previously.

(It's not preloaded HSTS so it would have to be learnt from a previous,
unattacked connection.)

I know that the unbypassable errors for some sites upset the more technically
minded people, but I think that incidents like this show its value.

The CloudShark trace shows what appears to be Firefox connecting to the GitHub
IP address, but the server clearly isn't GitHub from the config. The server
appears to be configured to accept the client's ciphersuite preference, but
doesn't support DHE nor ECDHE.

The server is also only 9ms from the client - that's clearly not crossing any
oceans. I'd also guess that the server is overloaded at the time because the
ServerHello (which doesn't take significant processing to generate in this
case) takes 900ms to come back.

Sadly, it appears to show the user overriding the certificate error and
talking to the server anyway :( Hopefully that was a fresh FF install just to
see what would happen (which would explain why HSTS didn't prevent the
override).

Lastly, the certificate appears to be self-signed, but the Authority Key Id
doesn't match. One assumes, based on "OpenSSL Generated Certificate" that
OpenSSL was used, but the person may have had some trouble. I'd guess that
they generated a CA certificate first (with the same Subject) and then signed
the certificate in question as a leaf. Many of the tutorials that you'll find
online are for that sort of setup so perhaps they weren't very familiar with
X.509 certificates.

~~~
bobcattr
didn't know of HSTS, thanks.

where would one keep up with stuff like that other than keeping up with new
rfc's?

~~~
ivanr
I maintain a complete guide to SSL/TLS deployment:

SSL/TLS Deployment Best Practices <https://www.ssllabs.com/projects/best-
practices/>

~~~
hnolable
You may want to integrate some of the advice from here in your HSTS section:

[http://coderrr.wordpress.com/2010/12/27/canonical-
redirect-p...](http://coderrr.wordpress.com/2010/12/27/canonical-redirect-
pitfalls-with-http-strict-transport-security-and-some-solutions/)

It seems even github is susceptible to this. That is, for people who type
www.github.com into their browser rather than github.com. They both did the
redirect wrong, as well as left off HSTS of <https://www.github.com>.

------
moxie
To clarify, this looks more like someone turning off SSL access to GitHub than
a proper MITM attack in the traditional sense.

The certificate in that link is just a self-signed certificate, not something
signed by a CA:

Issuer: C=US, ST=Some-State, O=github.com, OU=github.com, CN=github.com
Subject: C=US, ST=Some-State, O=github.com, OU=github.com, CN=github.com

So your browser will warn you that you are not making a secure connection.
Firefox users, for instance, will have to make 5 clicks to get through that
warning and visit the page.

I think "China turns off SSL access to GitHub" might be a more appropriate
title.

~~~
fintler
I don't think there's proof of China doing anything here. Perhaps someone on
OP's coffee shop WiFi is poisoning arp tables and forging certs.

This seems really sloppy for China. Without further proof, I don't think it
was the govt.

~~~
moxie
Agreed there's nothing in the data to directly suggest government involvement.

It's only "sloppy," though, when conceptualized as a MITM. China does have an
extensive history of censoring access to sites, and recently censored access
to GitHub entirely IIRC. It could be that they decided to block SSL access,
but allow HTTP access, and this is how they implemented that.

~~~
teawithcarl
Everything in my bones (25 years, 中文研究, China research) tells me the China
government is directly involved with this. China is corrupt beyond belief, and
any smaller destabilization can lead to further problems.

I agree that this may be a further extending of the "New Years train ticket"
block on Github.

It may also be new toying after the recent "experiment". Leaving Github
without SSL inside China still makes trouble - China's insidious corruption at
the very top is subtle, incremental small steps, all designed for the "long
game".

It may also be raw mercantilism ... as with Google, Twitter, and Facebook long
before this.

~~~
seanmcdirmid
As an sort of old china hand, china is corrupt but not beyond belief, there
are plenty of countries that are much more corrupt, even India is worse than
china and they even have democracy.

The level of sophistication that the GFW seems to be achieving is disturbing.
We've had certificate attacks before, perhaps they are testing something out
that will be deployed more broadly to solve there "gmail" problem?

------
songgao
This reminds me the Firefox certificate "bug"[1] two years ago. A China
certificate root server was added into trusted servers in Firefox and Chinese
hackers started to submit bug report regarding this, since people don't trust
certificate servers run by China government. Man-in-the-middle attack was
exact what Chinese hackers worried about.

If they put this fake certificate in a certificate root server that's in the
trusted server list, they can easily get anyone's account who's using affected
browsers.

It's weird that they start with Github. It's not a website that's popular
among human activists or any other people that China government might be
interested in. Instead, it's popular among programmers and hackers, who are
the main group and forces in China to help people bypass GFW to access blocked
content. I suppose this attack might be what the government uses to test
reaction and capability of hackers.

Seriously, this is really, really, bad.

[1] <https://bugzilla.mozilla.org/show_bug.cgi?id=542689>

EDIT: added link for bug report

~~~
khuey
If CNNIC is complicit in a MITM attack there will be a paper trail (namely a
certificate signed by them) proving their involvement. To this day nobody has
produced a cert signed by CNNIC that was used for a MITM attack. There's no
reason to believe that CNNIC is bad/evil/whatever other than their affiliation
with the PRC.

Disclosure: I work for Mozilla, but not on security.

~~~
songgao
Thanks for the reply. Glad to see some guy from Mozilla here!

You are right there's no reason to believe that CNNIC has to be
bad/evil/whatever, but we cannot assume CNNIC would never be bad/evil either.
We have to look at its history, and what's behind it.

When something turns bad, it won't throw out an announcement beforehand. And
we need something that can handle this in time.

I'm thinking about something like this: in addition to the trusted root server
list, keep another list, e.g., _less trusted root servers_ ; besides normal
update program, put a special piece of code in the browser that allows firefox
team to delete certain root server from _less trusted root servers_ on the
air. By "on the air", I mean not needing a full version update, or restarting
the browser. It can warn the user, but it should not be possible to canceled
the deletion.

~~~
khuey
That's something that we've considered doing. I'm not sure what the current
state is. I suspect there's a bug somewhere on bugzilla.mozilla.org for
implementing a cert blocklist that does not require a full update.

------
moonboots
Fortunately, it looks like Chrome prevents users from clicking past the ssl
errors. This Chinese chrome screenshot[1] shows that there's only a back
button (for English versions of this page, see [2]). Unfortunately, it appears
that IE allows users to click past the errors[3]. I'm also interested in how
the 360 browser[4], which has been gaining market share in China, handles the
error.

Does anyone have any theories why China would use a self signed certificate
when it's very indiscreet? A lot of users will just click through if given the
opportunity (around 60% in chrome before new security measures prevented
it[2]), but I doubt many users with truly sensitive private repos would do
this.

[1]
[https://twitter.com/GreatFireChina/status/295236912594186240...](https://twitter.com/GreatFireChina/status/295236912594186240/photo/1)

[2] <http://www.imperialviolet.org/2012/07/19/hope9talk.html>

[3]
[https://twitter.com/chenshaoju/status/295139636718743552/pho...](https://twitter.com/chenshaoju/status/295139636718743552/photo/1)

[4] <http://news.ycombinator.com/item?id=4499168>

------
jacquesm
What bugs me about stuff like this is that there will always be mercenaries,
guys just like you and me that will do _anything_ as long as it pays. The
Chinese government wouldn't stand a chance if they had to do this stuff
themselves. Mercenary coders are nothing new, we have them in every country
(and sysadmins, companies and so on).

But you have to wonder what goes on in their heads, what mindset would prompt
you to sell out like that.

~~~
btilly
We should be worried about mercenaries when it comes to malware, Russian
botnets, and the like.

In the case of the Chinese government, I believe the bigger problem is
patriots. They honestly believe that they are doing the Right Thing. So did
the people who wrote Stuxnet.

~~~
X-Istence
Just to be clear, Stuxnet is claimed to have been written by the US
government/Israeli Government, not by the Chinese.

~~~
btilly
Yes.

And my claim is that it was likely written by people who consider themselves
patriots, not mercenaries.

------
No1
Some speculation as to why they're targeting Github:

\- the Chinese gov't is trying to identify users/developers of train-ticket-
purchasing bots [1]

\- they are is interested in capturing some intellectual property contained in
private repos

\- it's just an exercise to watch & learn how computer-literate users
circumvent a MITM attack

Given the recent Github blockade, I'd go with the first.

[1] <http://www.techinasia.com/github-blocked-china/>

------
runarb
Many are mentioning the Chinese government, but are there any signs that they
are involved?

How do we know that this isn't just a hijack of a Chinese isps dns server or
something similar? Maybe the same that happened to Goolge Morocco just a
couple of days ago ( [http://arabcrunch.com/2013/01/breaking-google-morocco-
google...](http://arabcrunch.com/2013/01/breaking-google-morocco-google-co-ma-
is-hacked.html) ).

------
qschneier
FYI there is a petition on whitehouse.gov to deny those people who work on GFW
entry US. [https://petitions.whitehouse.gov/petition/people-who-help-
in...](https://petitions.whitehouse.gov/petition/people-who-help-internet-
censorship-builders-great-firewall-china-example-should-be-denied-entry-
us/5bzJkjCL)

~~~
X-Istence
We should deny all those companies that have developed tools of censorship
access to government contracts and deny them the right to work in the United
States ... oops, there goes almost every single major networking manufacturer!

Cisco:
[http://newsandinsight.thomsonreuters.com/California/News/201...](http://newsandinsight.thomsonreuters.com/California/News/2011/06_-_June/Cisco_aided_Chinese_Internet_censorship,_lawsuit_says/)

Juniper also implicated: [http://www.cfr.org/china/us-internet-providers-
great-firewal...](http://www.cfr.org/china/us-internet-providers-great-
firewall-china/p9856#p4)

Blue coat:
[http://online.wsj.com/article/SB1000142405297020368750457700...](http://online.wsj.com/article/SB10001424052970203687504577001911398596328.html)

Websense: [http://opennet.net/west-censoring-east-the-use-western-
techn...](http://opennet.net/west-censoring-east-the-use-western-technologies-
middle-east-censors-2010-2011)

The list goes on ...

------
j45
It sucks my client will be able to say he was right about now allowing source
code to be hosted on github.

(We ended up setting up a gitlab box and it works just as well)

~~~
AndrewKemendo
I find this a sad commentary about your (and certainly others) relationship
with your clients.

~~~
venomsnake
There is nothing wrong in insisting the repository to be hosted on the client
metal. The way things were done in the ancient times before the cloud to
become the favorite buzzword of the month.

~~~
j45
I agree. The cloud isn't new. VPN's have existed for ever as well as client-
mainframe.

The perception that the cloud is somehow re-invented is in fact the saddening
thing. It's just more accessible and faster than in the fast, but ultimately
you can't manage infrastructure by abdication and farming it out.

There's always an uneasy balance between security and convenience.

------
shimon_e
In China now. Ping to github is 280ms. The cert I receive is valid. So either
they stepped up the game or it isn't universal.

~~~
seanmcdirmid
Even the Chinese gov does A/B testing.

~~~
freewizard
It's more likely capacity limit than A/B testing. Returning arbitrary response
is consuming more resource compared to cutting off connection (sending TCP
RST).

------
xfs
I guess it was a planned public test or technical verification of certain
larger project about live traffic decryption on national level. There really
isn't a plausible political reason of github being targeted. Maybe targeting
github can get data about user response or verify scalability of the
infrastructure given recent high https traffic volume from China to github.

~~~
dbaupp
It seems strange that they would target a site whose users are exactly the
people most likely to detect and understand (and make a fuss about) internet
peculiarities.

------
dguido
I was wondering when Github was going to start supporting HSTS and 2-Factor
Auth. I'm betting that it gets bumped in priority after this event. Nothing
like an incident to move along security requirements!

<http://dev.chromium.org/sts>

<https://www.duosecurity.com/features>

~~~
moxie
I don't think either would help in this situation. HSTS helps prevent SSL
stripping attacks, which whoever is denying SSL access to GitHub doesn't need
to bother with.

2FA serves as an annoyance to phishers, but whoever is doing this network
attack has direct access to your session cookie.

------
matthewrudy
I should report that from my Shanghai based VPS I don't get this problem.

Perhaps this is localised, or was just a trial for a few hours.

<https://gist.github.com/4650029>

------
teawithcarl
Read the Twitter stream - affects people inside China.

Still, shows the depth and corruption the China (gov't).

<https://twitter.com/search/?q=Github%20SSL>

------
kevingadd
How would this fake cert work? It doesn't seem to originate with a root or
have any associated information. Do browsers actually accept certs that look
like this?

~~~
dublinben
It would work if users accepted the self signed certificate upon receiving the
warning.

<http://pic.twitter.com/xOxhoyzp>

------
qschneier
Censorship in China is a big business, for the companies that have connections
to the officials, for the universities that rely on the funds, and for the
officials who use this as a stepstone for their career. It is so common that
you can even find many fresh graduates who worked for the GFW in the job
market.

------
chimeracoder
How long ago did this start? I wonder if it has anything to do with some of
the issues with Github I (and others) were noticing on Friday[0]

[0] <https://twitter.com/davidbalbert/status/294941563673522176>

------
teawithcarl
Here's another (safe) "tweet" by China geek alerting the situation.

RT @chenshaoju 无锡电信实际测试GitHub已经遭到SSL中间人攻击。 <http://bit.ly/X49oPK>

------
darkhorn
How did GitHub learned that there were man-in-middle attack?

------
dpeck
The natural result of the "code is speech" argument?

------
hackfisher
Bad news, access to github is unsafe for people in china now.

