Re: [whatwg] Proposal: Specify SHA512 hash of JavaScript files in <script> tag

Sorry for the late response.

Igor Minar, 2014-02-05 03:08 (Europe/Helsinki):
> I've been in discussions in the past where developers expressed concerns
> about inability to verify that the bits delivered from CDN were the same
> bits as the ones they reviewed and tested against during development.
>
> It's very common to pull popular libraries (like jquery, angular,
> underscore, bootstrap, etc) from a CDN, while delivering the html, css and
> app specific bits from a different server. In this scenario the developer
> has to blindly trust the CDN provider to disallow any kind of modification
> of the bits.
>
>  From what I read this is the reason why financial and healthcare apps can't
> use 3rd party CDNs at all.

I understand the problem and I have hit the same issue by myself.

However, the suggested hash signature is far from enough. Most popular 
libraries have means to load additional files and plugins and the 
suggested hash is able to "sign" only the main file. If you cannot trust 
the CDN provider, you cannot trust that the rest of the files have not 
been modified. An attacker could use *any* file in the CDN network for 
an attack. If your signature cannot cover *all* files, adding the 
signature is wasted effort. There's no need to provide any additional 
tools for false sense of security.

In addition, financial and healthcare apps may have to deal with rules 
set by local laws in addition stuff required by strict minimum for 
mathematically sound encryption. As a result, such apps may have to 
distribute copies of all the libraries by themselves in the future, too, 
regardless of any signature support for 3rd party distributed content. 
And if such app provider simply switched to SPDY, the service would 
highly probably work faster than the combination of plain HTTPS and CDN 
can provide.

In the end, even if we had such a hash signature system (where 
authenticity of hash is provided by TLS of the main site), when it would 
be supported well enough to be trusted? 10 years has not been enough to 
get rid of MSIE 6.0... If you need security, the only real option is to 
serve content from servers that you can trust and use TLS to encrypt the 
traffic.

-- 
Mikko

Received on Thursday, 26 June 2014 06:19:32 UTC