EFF: Wider Use of HTTPS Could Have Prevented Attack Against GitHub

itwbennett writes The attack against GitHub was enabled by someone tampering with regular website traffic to unrelated Chinese websites, all of which used a JavaScript analytics and advertising related tool from Baidu. Somewhere on China's network perimeter, that analytics code was swapped out for code that transparently sent data traffic to GitHub. The reason GitHub's adversaries were able to swap out the code is because many of the Chinese websites weren't encrypting their traffic.

Comments

Today's "news" brought to you by...

[JustinKSU]

duh. better security == better security.

HTTPS needs to be the default

[Anonymous Coward]

You cannot tamper with the contents of a HTTPS stream.

But don't be under the illusion that that actually provides security, after all, if you can't MITM, you just need to poison the watering hole.

Re:HTTPS needs to be the default

[krept]

I didn't get your comment until further down... HTTPS does provide security, it just doesn't guarantee it. Especially where China could probably install any client they want on many many computers.

Re:HTTPS needs to be the default

[gl4ss]

ah but the dos wasn't coming from china.

instead, it was coming from any browser in the world that fetched a page(or rather, piece of tracking javascript code from baidu) _in_ china. they still would have only had to mitm the baidu.

and they probably already were sitting on the pipe to baidu or were able to divert the traffic. that's why people are saying that it's the state, because either it's the state OR baidus internet tap is hacked.

HTTPS?

[Coren22]

How will HTTPS help in this situation? The Great Firewall could just as easily act as a MITM attack and still do the exact same attack? Are we even sure it was the firewall and not Baidu themselves?

Re:HTTPS?

[smooc]

I understood that part of the attack also happened from international visitors to Baidu. Would a MITM of the Great Firewall still have worked then or would it at least have been partially mitigated?

Re:HTTPS?

[Anonymous Coward]

because you'd have to accept the certificates. But you're correct it's unlikely that it would have helped much as we know that governments are able to generate arbitrary certificates (with preaccepted CAs).

That said I believe DNSSEC does help this (If I recall correctly part of DNSSEC is creating TCP connections with SSL using the DNS signed certificate. but I could be thinking of a different extension)

Re:HTTPS?

[Anonymous Coward]

Agreed. And in fact one guy narrowed down the source of the packet injection to the Great Firewall (China Unicom): Pin-pointing China's attack against GitHub.

Re:HTTPS?

[IamTheRealMike]

The Great Firewall could just as easily act as a MITM attack

This must be a new use of the phrase "just as easily" that I haven't encountered before.

Line rate DPI is already expensive and slow. The Great Firewall has in the past routinely suffered from weird hotspots or outages at peak times where banned keywords were not always being spotted.

The injection technique that the GFW was using in this instance is very simple: on spotting a particular byte pattern in the packet stream, write three (probably pre-formatted) packets into a network port, sit back, see what happens. There were always exactly three packets and attempting to get normal behaviour out of the MITM TCP stack didn't work, meaning there probably is no stack.

Now throw "completely intercept the TCP handshake and redo it, then perform an SSL handshake on the client end, then perform ANOTHER connection to the Baidu server, then obtain a fake cert without tipping off the western browser/OS makers whose browsers you are trying to hack, THEN decrypt massive amounts of traffic (basically all traffic to the intended host) at line rate" .... yeah good luck. It can theoretically be done but it'd require entire datacenters of machines doing nothing but decrypting and re-encrypting Baidu.

Then remember that this attack works by converting Chinese people abroad into a botnet. So the moment the Chinese fake cert is detected it would be revoked immediately. Attack over.

No way. It will never happen. If China wants to convert Baidu users into a weapon then it is MUCH simpler for them to simply ...... put a gun to the CEOs head and say "you're inserting our js into your code whether you like it or not". That way Baidu pays all the costs of serving their code and they don't need any large new infrastructure to do SSL MITM.

Re:HTTPS?

[Coren22]

This is China we are talking about. They just ask Baidu to give them a copy of the SSL cert. I administer devices that are 1U and can act as a MITM at 10Gbit speeds, they are called load balancers. How hard would it be to reprogram a load balancer to also insert a script? Not very.

Frankly, it would be just as easy to make Baidu serve up the script for them, or even hack the Baidu servers to add the "malicious" script themselves. This is a government, they have the power.

Re:HTTPS?

[orasio]

There's also another bit that I fail to understand.

If the Chinese Firewall guys wanted to DoS github, they could just do it. Playing synthetic traffic against github, for example.
Instead, we say that they hijacked their users computers, so they could generate traffic that in the end would have to go through the firewall.

From the firewall point of view, that wouldn't be a DDoS, because the attacker is always them, no distribution happens. It doesn't make sense, and it's a lot more work than just doing the DoS attack themselves.

Of course, MITM is something they can do, they might be doing that kind of thing, and hijacking clients computers for other reasons, but for this attack, it doesn't make a lot of sense.

Re:HTTPS?

[IamTheRealMike]

Frankly, it would be just as easy to make Baidu serve up the script for them

Yes. That's exactly what I said in the last paragraph. Did you read the post all the way to the end?

Obviously China can build the equipment needed to do a massive MITM attack on Baidu. But it would be a big step up from what they're currently doing, cost wise. So it makes little sense for them to do that, given they'd need to coerce the private keys out of Baidu anyway. At that point they may as well just re-use Baidu's existing equipment for termination of SSL.

Bear in mind there are multiple subtle cases that interact with different systems in different ways.

The base case, that we have here, is no SSL. GFW injects packets, not much anyone can do about it.

The next step up is PRC minting fake certificates. However, CNNIC just got revoked by Chrome for gross negligence, so obviously browser makers are not unwilling to do that, and other than Hong Kong Post Office PRC doesn't control any other CAs. If one was found to be doing a MITM attack on Baidu it'd be immediately revoked again - game over.

So then the next step up is Chinese government coercing Baidu to give up their private keys. However PKI rules say that if a private key is lost either through coercion or theft the certificate is revoked. This happened to Lavabit: once they were forced to give up their key by court order Verisign revoked the cert explaining that industry policies required it to do so. So if Baidu started serving malicious Javascripts then most likely Baidus SSL cert itself would be revoked, on the assumption that a respectable company would not distribute malware under its own volition. This would have the effect of nuking most Baidu ads or analytics outside of China and probably breaking websites, but assuming the Chinese websites care, they would just adjust their code to stop including Baidu stuff for foreign users and that's the end of that.

Additionally even if the issuing CAs didn't want to revoke Baidu entirely, I suspect Google/Microsoft would add the pages to the SafeBrowsing blacklist for malware distribution and the outcome would be the same.

China could also try coercing ALL keys out of ALL websites and doing MITM on ALL of them, but the amount of effort required to do that would be astronomical.

So the conclusion is the same - SSL is the next step in this arms race.

Re:HTTPS?

[WuphonsReach]

HTTPS (SSL) alone will not stop attacks like this where any registrar trusted by the browser can issue certificates for any site that they want to.

HTTPS combined with DNSSEC + DANE would stop attacks like this. Because now the domain owner can say a few things:

- This is the only CA allowed to issue certificates for my domain
- My certificate is X, and not anything else

In short - admins need to put pressure on their DNS providers to provide DNSSEC for their domain records, after which DANE can be used to provide security for the SSL certificates associated with your domain.

EFF Link

[gQuigs]

https://www.eff.org/deeplinks/...

As if ...

[gstoddart]

So basically if China allowed HHTPS a non-Chinese server wouldn't have been DDoS'd.

Like China will give a crap about that.

Fake certificate...

[zoffdino]

Can HTTPS help when even the certificate is faked? I can barely hold any trust about anything from China these days.

Re:Fake certificate...

[Anonymous Coward]

It can if you've explicitly distrusted all known CA root certificates known to be associated with China's current regime, like CNNIC. Which I'd highly recommend doing.

Re:Fake certificate...

[birdspider]

google will do exacly this in chrome, and mozilla is currently discussing it http://arstechnica.com/securit... . Of course CNNIC is not amused (bottom of article)

Re:Prediction

[Midnight Thunder]

Regular http will be basically dead by 2020.

It will be if setting up an HTTPS and virtual-hosts using HTTPS becomes as easy as setting up a basic HTTP server.

The main issues as the moment is that getting a certificate is complicated, expensive and then dealing with setups is not always straightforward. Now, that is just for a basic Apache server. Create scenarios where you have load balancers, Apache servers serving multiple domain names and applications servers fronted by Apache and you have another set of problems.

HTTPS needs to become easy to setup for anyone, and not just necessary.

I may have missed some of the advances in simplification, so I would welcome any new information here.

Re:Prediction

[Anonymous Coward]

Is for free cheap enough? https://letsencrypt.org/ Granted, letsencrypt is a few months away, but there are already plenty of other sources available for free domain verified SSL/TLS certificates and have been for quite some time. And it really isn't that difficult to set up as you seem to believe.

Maybe it's time...

[jenningsthecat]

...for web sites that are https-capable to start refusing all non-https connections. That might go along way to ensuring the ubiquity of https...

DANE

[clenhart]

Sounds like it's time for DANE, http://en.wikipedia.org/wiki/D.... SSL certificates via DNS

Re:DANE

[tepples]

Good luck getting last mile ISPs and domain registrars to offer reliable DNSSEC resolution.

Re:DANE

[marcosdumay]

The registart choice is up to you. Just choose one that offers DNSSEC.

The ISP part is harder, but if applications stopped using their DNS when DNSSEC is not available, they would adopt it in a heart beat.

Re:DANE

[tepples]

if applications stopped using their DNS when DNSSEC is not available

Then ISPs would point the finger at application developers when the applications stopped working.

Re:DANE

[marcosdumay]

No need to make your applications stop working. Just try the default DNS, and if it fails use another server. Also, cache the failure during the session, so the ISP will lose your metadata.

Re:DANE

[tepples]

Just try the default DNS, and if it fails use another server.

Which would require the application to hardcode the IP address of a recursive DNSSEC server. Who would operate this server? Would 8.8.4.4 and 8.8.8.8 be appropriate, or ought this to be the job of the publisher of each individual application?

Re:DANE

[marcosdumay]

Yes, one'd have to hard-code it. It's up to the developer to decide what server to hard-code, obviously. Context will tell what's more appropriate, by I'd gess most big projects would use their own servers.

Cost of an IPv4 address for SNI-ignorant clients

[tepples]

Is for free cheap enough? https://letsencrypt.org/

Not if you run a small site that doesn't yet have its own dedicated IPv4 address, and you have to serve older clients that lack support for Server Name Indication, such as Internet Explorer on Windows XP, Android Browser on Android 2.x, and urllib2 on Python 2. SNI-ignorant clients can see only the first certificate on port 443 of a given IP address, not certificates associated with other hostnames on virtual hosting. A subjectAltName certificate works only if all listed hosts share the same owner, and this is unlikely on shared hosting. So you'll have to lease an IPv4 address for your site, and we're pretty much out of those.

Re:Prediction

[daveime]

www.openssl.com Basic SSL certificates free with an email address, wildcard SSL $59 with proof of address and identity (i.e. passport and 2 recent billing for utilities gas electric water etc) good for 1 year. How difficult could it be?

Re:Prediction

[jellomizer]

Exactly.

It is easier to setup a secure SSH server then a HTTPS server. We have the issue of Certs, and the browsers only wanted trusted certs, If you don't go threw the trusted method, then you get scarry Alerts on how such a horrible site owner you are, for not shelling out cash to be on the good guys cert list.
 

Re:Cost of an IPv4 address for SNI-ignorant client

[WuphonsReach]

Eh... why support such out of date clients?

WinXP went out of EOL about a year ago. Usage is down to about 16%. And they can use alternative browsers or SSL libraries to deal with SNI. At this point, anyone left on WinXP is not worth the cost of support.

Android 3.0 came out in 2011. Only 7.3% of Android devices run a version older then 4.0.

At some point, you have to draw a line in the sand and say "we will not support that". Those older devices are insecure, don't support modern features, and increase your support and development costs by a large amount. If you can reach 90% of your audience for X cost, trying to reach 99% for X*10 or X*100 is not worth it.

It's the same deal as HTML5. Two years ago? It would have been near-suicide to base your website solely on HTML5. Today? There's no reason not to go 100% HTML5.

SNI support is now widespread enough that you don't need to worry about it.

Resistance.

[DrYak]

The main issues as the moment is that getting a certificate is complicated, expensive and then dealing with setups is not always straightforward. Now, that is just for a basic Apache server. Create scenarios where you have load balancers, Apache servers serving multiple domain names and applications servers fronted by Apache and you have another set of problems.

Which could all be mitigiated.
- Free CA (like CACert or StartCom)
- Server Name Indication (serving several virtual domains, each with its own certificate, but all mapping to the same IPv4 address)
- IPv6 (enabling you to assign 1 different address for each virtual domain)
etc.

But that would require work. Lots of it. And rethinking the infrastructure and reorganising it in a way that actually works better and is more forward upgradeable.

So yeah, expect HTTP to day in the 20s...
2120s...

Re:Cost of an IPv4 address for SNI-ignorant client

[tepples]

And they can use alternative browsers

Can in theory; can't in practice because IT refuses to install them.

or SSL libraries

How do you install an alternate SSL library into an existing application?

Re:Cost of an IPv4 address for SNI-ignorant client

[tepples]

Android 3.0 came out in 2011.

Only for tablets. Phones were stuck on 2.3 throughout the entire 3.x series.