Slashdot Mirror


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.

48 comments

  1. Prediction by Anonymous Coward · · Score: 0

    Regular http will be basically dead by 2020.

    1. Re:Prediction by Midnight+Thunder · · Score: 4, 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.

      --
      Jumpstart the tartan drive.
    2. Re:Prediction by Anonymous Coward · · 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.

    3. Re:Prediction by daveime · · Score: 1

      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?

    4. Re:Prediction by jellomizer · · Score: 1

      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.
       

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    5. Re:Prediction by Anonymous Coward · · Score: 0

      How about free certificates that don't flag your site with an ominous warning... or worse (in the case of Chrome): force them to type "proceed" (because that is ever so intuitive).

    6. Re:Prediction by Anonymous Coward · · Score: 0

      Firefox does support opportunistic encryption for HTTP now which allows self-signed certs (since it's not showing a lock icon or anything like that). Not sure if there's a way to pin it to require future visits to an opportunistically encrypted site also be encrypted and use the same cert (that would make it like SSH). Hopefully the other browsers will also add support for that and web servers will have a dead-simple configuration for it (since you don't care what the cert is, the server can just auto-generate it like an SSH server does).

  2. Today's "news" brought to you by... by JustinKSU · · Score: 3, Funny

    duh. better security == better security.

  3. HTTPS needs to be the default by Anonymous Coward · · 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.

    1. Re:HTTPS needs to be the default by krept · · Score: 2

      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.

      --
      None of us know everything. Therefore we're all naïve.
    2. Re:HTTPS needs to be the default by gl4ss · · Score: 1

      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.

      --
      world was created 5 seconds before this post as it is.
  4. HTTPS? by Coren22 · · Score: 1

    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?

    --
    APK likes to ask for responses to the same things over and over. Maybe he just likes the responses?
    1. Re:HTTPS? by smooc · · Score: 1

      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?

      --
      - In Memoriam: Jeroen de Bruin (1972-2004), bye bro
    2. Re:HTTPS? by Anonymous Coward · · 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)

    3. Re:HTTPS? by Anonymous Coward · · 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.

    4. Re:HTTPS? by IamTheRealMike · · Score: 4, Informative

      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.

    5. Re:HTTPS? by Anonymous Coward · · Score: 0

      >THEN decrypt massive amounts of traffic (basically all traffic to the intended host) at line rate" .

      You're assuming the Chinese are used to getting 100 mbits to non-Chinese sites. That is not the case. Inside China, it's fast. From China to elsewhere, it can be painfully slow, often purposefully so.

      >So the moment the Chinese fake cert is detected it would be revoked immediately. Attack over.

      Have the revoked the current Chinese fake cert that is being used?

    6. Re:HTTPS? by Anonymous Coward · · Score: 0

      they'd have to decrypt, re-sign (with a new cert generates from a CA trusted by clients) and re-encrypt the traffic. Thats slow and expensive to do, and then browser vendors would just nuke the CA (as Google wants to do for the other similar case).

      So its not "easy", and its very detectable.

    7. Re:HTTPS? by Coren22 · · Score: 4, 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.

      --
      APK likes to ask for responses to the same things over and over. Maybe he just likes the responses?
    8. Re:HTTPS? by orasio · · Score: 1

      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.

    9. Re:HTTPS? by IamTheRealMike · · Score: 1

      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.

    10. Re:HTTPS? by Anonymous Coward · · Score: 0

      I am very sad to say that the Chinese web sites using over HTTPS would not have helped at all--indeed, it would have made the problem worse. Marketers have this perverted love affair with third-party analytics tools. When an evil Javascript payload gets pulled in from an analytics outfit (like Google or Baidu), or worse, from an agent of demonic possession like Webroll, the script is set up to fetch they payload into the user's web page using the same protocol (HTTP or HTTPS) as the main page. This means that all the spawn from these helpful tools get loaded regardless of whether you have encryption or not. So no, using HTTPS would not have helped. All those Chinese sites were already using Baidu's analytics tools. Some of these sites may do so because they like the analytics, and some because the CCP has ways to coerce things.

      So how does using HTTPS make things even worse? Well, in addition to the usual three-way TCP handshake is the even longer TLS handshake. You have to do all that before you can get around rejecting a certificate or anything like that.

      I don't have much good to say about analytics tools that use third-party websites.

    11. Re:HTTPS? by WuphonsReach · · Score: 1

      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.

      --
      Wolde you bothe eate your cake, and have your cake?
    12. Re:HTTPS? by Anonymous Coward · · Score: 0

      Not going to happen. Google said no to DNSSEC/DANE. Mozilla pretty much did as well. At the moment we're stuck with the HTTPS key pinning header which doesn't protect first visits.

  5. EFF Link by gQuigs · · Score: 5, Informative
  6. As if ... by gstoddart · · Score: 3, 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.

    --
    Lost at C:>. Found at C.
  7. Fake certificate... by zoffdino · · Score: 4, Interesting

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

    1. Re:Fake certificate... by Anonymous Coward · · 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.

    2. Re:Fake certificate... by Anonymous Coward · · Score: 0, Insightful

      Most people can barely hold any trust about anything from the US these days. That includes its people, you would have to be clinically insane to trust americans.

      China are no worse than you. Probably a little better in fact.

    3. Re:Fake certificate... by birdspider · · Score: 1

      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)

  8. Wide ban by Anonymous Coward · · Score: 0

    Conclusion: Login with SSH keys should be banned immediately.

  9. ITWORLD=fails by Anonymous Coward · · Score: 0

    From the same publication that brought you: "No, it’s not always quicker to do things in memory "
    see:
    http://developers.slashdot.org/story/15/03/25/1430251/no-its-not-always-quicker-to-do-things-in-memory

    http://www.itworld.com/article/2901453/no-its-not-always-quicker-to-do-things-in-memory.html

  10. Maybe it's time... by jenningsthecat · · Score: 1

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

    --
    'The Economy' is a giant Ponzi scheme whose most pitiable suckers are the youngest among us and the yet-unborn.
  11. DANE by clenhart · · Score: 1

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

    1. Re:DANE by tepples · · Score: 2

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

    2. Re:DANE by marcosdumay · · Score: 1

      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.

    3. Re:DANE by tepples · · Score: 1

      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.

    4. Re:DANE by marcosdumay · · Score: 1

      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.

    5. Re:DANE by tepples · · Score: 1

      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?

    6. Re:DANE by marcosdumay · · Score: 1

      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.

  12. Cost of an IPv4 address for SNI-ignorant clients by tepples · · Score: 1

    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.

  13. Re:Cost of an IPv4 address for SNI-ignorant client by WuphonsReach · · Score: 1

    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.

    --
    Wolde you bothe eate your cake, and have your cake?
  14. Open source mentality by Anonymous Coward · · Score: 0

    nice... blame the users, not the design/system; typical open source mentality. Reminds me of a certain s/w development process: it's not wrong, you're doing it wrong.

  15. Re: Cost of an IPv4 address for SNI-ignorant clien by Anonymous Coward · · Score: 0

    I need to support xp IE 7, which is still about 10% of my company's sales. That adds up to 10k a month. I'd say they're worth the effort.

  16. Resistance. by DrYak · · Score: 1

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

    --
    "Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
  17. You gotta understand this ... by Anonymous Coward · · Score: 0

    ... to many Westerners China is THE DE-FACTO PURE EVIL RE-INCARNATED !

    They do not need to talk sense

    They do not need to talk logic

    All they need to know is that if it has something to do with China, then CHINA is the PENULTIMATE ORIGINAL SIN, period

  18. Re:Cost of an IPv4 address for SNI-ignorant client by tepples · · Score: 1

    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?

  19. Re:Cost of an IPv4 address for SNI-ignorant client by tepples · · Score: 1

    Android 3.0 came out in 2011.

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