• Posts
  • RSS
  • ◂◂RSS
  • Contact

  • SRI against the Great Cannon?

    September 19th, 2015
    tech  [html]
    One way to make things load faster is to put them closer to your users. Instead of serving everything from your main data center, you take copies of your resources and you distribute them all around the world. When someone in New York visits your page and loads your scripts they should be served from New York, while when someone does the same from Hong Kong they should be served from Hong Kong.

    This is a CDN, and they're great. The problem is, they're expensive to build. You need to put servers all over the world, on lots of different networks, if you want to be as close to people as possible. Which means that unless you're a huge company you pay an external CDN to distribute your resources for you.

    The problem now is that if there's a security breach at the CDN someone malicious could make changes to the javascript on the CDN and take control over your site. By using the CDN you make your site dependent on the security at your CDN company.

    There's a new HTML feature, however, that means you can fix this problem for new browsers. It's called Subresource Integrity (SRI) and lets you specify hashes for resources. Traditionally, when you include a script from your CDN you'd write html like:

       www.jefftk.com/foo.html:
         ...
         <script src="//cdn.jefftk.com/foo.js"></script>
         ...
    
    With SRI, you can add an integrity attribute that lets you specify the hash that the correct version of foo.js has:
       www.jefftk.com/foo.html:
         ...
         <script src="//cdn.jefftk.com/foo.js"
                 integrity="sha256-..."></script>
         ...
    
    After downloading the script, if the hash doesn't match the expected one then your browser knows something is wrong and doesn't run it.

    This is great, and any time you're putting a script on someone else's CDN you should use it. And people are starting to use it: GitHub just announced they've started with it on their CDN. Unfortunately, their announcement says something that implies SRI will go farther than it actually can:

    Widespread adoption of Subresource Integrity could have largely prevented the Great Cannon attack earlier this year.
    They're referring to an attack against them and GreatFire.org via the Chinese government's "Great Cannon". The way this attack worked is that lots of sites include analytics or ads from the Chinese search engine Baidu. This looks vaguely like:
       www.jefftk.com/foo.html:
         ...
         <script src="http://baidu.com/ads.js"></script>
         ...
    
    The Great Cannon would intercept these requests to ads.js and for ~2% of them respond with an attack script instead of the expected ad-loading script. The attack script would load lots of resources from GitHub and GreatFire in the background. So millions of browsers of people outside of China who had just happened to load containing Baidu ads on it were now sending substantial unwanted traffic to the victim sites, enough to overload (DDoS) them.

    GitHub is suggesting that people could instead have written:

       www.jefftk.com/foo.html:
         ...
         <script src="http://baidu.com/ads.js"
                 integrity="sha256-..."></script>
         ...
    
    Then when the GreatCannon intercepted the request for baidu.com/ads.js and substituted something malicious the hash wouldn't have matched and the browser wouldn't have run the attack script.

    One objection to this is that if you're an active attacker that can change scripts as they pass then you could just as easily change the html as well to have the correct hash. First, this is really hard, with failures leading to broken scripts on pages. But more importantly, it ignores that the Chinese government can modify Chinese traffic but not all traffic. By rewriting Baidu's ad-loader they were able to affect any page with Baidu ads, not just ones served from China.

    The real problem with using SRI on this sort of ad-loader or analytics snippet is that Baidu etc need to be able to make changes to their scripts. They don't just release one version and expect everyone to run exactly that script forever: bugs, browser changes, etc mean they need updates. When they do make an update, though, the hash changes. How do you make sure the integrity hashes in all these html snippets stay in sync with the version changes? This is not practical: people need their snippets to be simple static html.

    The fix in this case is to use HTTPS for everything. The Great Cannon was able to modify the script because it was just loaded over HTTP. Use HTTPS for ads instead and it can't make these modifications anymore.

    (There's a simple rule for when to use SRI: if the same entity controls the html and also chooses what version of script to run, then SRI is a good fit. Otherwise you don't have a way to prevent hash mismatches.)

    Comment via: google plus, facebook

    Recent posts on blogs I like:

    Randal O’Toole Gets High-Speed Rail Wrong

    Now that there’s decent chance of US investment in rail, Randal O’Toole is resurrecting his takes from the early Obama era, warning that high-speed rail is a multi-trillion dollar money sink. It’s not a good analysis, and in particular it gets the reality…

    via Pedestrian Observations May 12, 2021

    Collections: Teaching Paradox, Europa Universalis IV, Part II: Red Queens

    This is the second part in a series (I) that examines the historical assumptions behind Paradox Interactive’s grand strategy computer game set in the early modern period, Europa Universalis IV (EU4). Last time, we took a look at how EU4 was a game fundame…

    via A Collection of Unmitigated Pedantry May 7, 2021

    Books and websites on babies

    Several people I know are expecting a first baby soon, and I wrote up notes for one of them. Might as well share here too: Medical:Scott Alexander’s Biodeterminist’s Guide to Parenting is an interesting read, and some parts are actionable.  If you live in…

    via The whole sky April 14, 2021

    more     (via openring)


  • Posts
  • RSS
  • ◂◂RSS
  • Contact