EFF: Wider Use of HTTPS Could Have Prevented Attack Against GitHub 48
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.
Re:Prediction (Score:5, Informative)
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: (Score:1)
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.
Cost of an IPv4 address for SNI-ignorant clients (Score:2)
Is for free cheap enough? https://letsencrypt.org/ [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
Re: (Score:2)
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 incr
Re: (Score:2)
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: (Score:2)
Android 3.0 came out in 2011.
Only for tablets. Phones were stuck on 2.3 throughout the entire 3.x series.
Re: (Score:2)
Re: (Score:2)
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.
Resistance. (Score:2)
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 [cacert.org] or StartCom [startcom.org])
- Server Name Indication [wikipedia.org] (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...
Today's "news" brought to you by... (Score:4, Funny)
HTTPS needs to be the default (Score:2, Interesting)
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: (Score:2)
Re: (Score:2)
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? (Score:2)
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: (Score:2)
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: (Score:1)
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: (Score:1)
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 [erratasec.com].
Re:HTTPS? (Score:5, Informative)
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? (Score:5, Insightful)
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: (Score:2)
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 eq
Re: (Score:2)
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 Do
Re: (Score:2)
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
EFF Link (Score:5, Informative)
https://www.eff.org/deeplinks/... [eff.org]
As if ... (Score:4, Insightful)
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... (Score:5, Interesting)
Re: (Score:1)
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: (Score:1)
google will do exacly this in chrome, and mozilla is currently discussing it http://arstechnica.com/securit... [arstechnica.com] . Of course CNNIC is not amused (bottom of article)
Maybe it's time... (Score:2)
...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 (Score:1)
Sounds like it's time for DANE, http://en.wikipedia.org/wiki/D... [wikipedia.org]. SSL certificates via DNS
Re: (Score:3)
Good luck getting last mile ISPs and domain registrars to offer reliable DNSSEC resolution.
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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 [google.com] be appropriate, or ought this to be the job of the publisher of each individual application?
Re: (Score:2)
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.