Re: Encrypting content stored on untrusted CDNs

On Fri, 02 Mar 2012 23:25:50 -0000, Ian Hickson <ian@hixie.ch> wrote:

> I've now specced this:
>
> http://html5.org/tools/web-apps-tracker?from=7011&to=7012
> http://www.whatwg.org/specs/web-apps/current-work/#http+aes-scheme
>
> If anyone would like to edit a spec of this that's independent of the  
> HTML spec, let me know, I'd be happy to move this to another spec.

Thanks!

I wonder whether the protocol name should be a bit more generic, e.g.  
http+enc. It would be silly to be stuck with that name if AES was cracked,  
or if other encryption schemes were found to be useful.

I was unable to find info whether AES-CTR gives any integrity assurance at  
block level. If it doesn't, then an attacker could corrupt selected blocks  
of the file transferred, and UA wouldn't be able to detect that during  
decryption. That could allow attacker to corrupt parts of image or video  
files in attempt to crash the browser.

If that is the case, and random access is needed, then perhaps some kind  
of hash tree needs to be used as well, e.g. URL specifies top hash and  
HTTP headers include part of hash tree relevant to the range requested.


<scope-creep>

It would be cool if http+aes did not trigger mixed content warning on  
https pages to allow cheap hosting of non-privacy-sensitive assets on  
HTTPS/SPDY pages (e.g. if attacker sees connection to Facebook servers,  
then seeing Facebook logo and CSS downloaded doesn't reveal much, but  
those assets could be publicly cacheable while maintaining integrity).

Unprotected headers are a problem, but maybe something can be done about  
it? Maybe allow only selected safe headers to be used by UA, and require  
content to match a hash (and type?) specified securely, e.g.:

<link type="text/plain"  
href="http+enc://sha1:%F7%FF%9E%8B%7B%B2%E0%9Bp%93Z%5Dx%5E%0C%C5%D9%D0%AB%F0@example.com">

would only accept a text file containing "Hello".

The above example also shows that a random key as URL-encoded ASCII is  
unlikely to be shorter than a hex or base64 representation.

-- 
regards, Kornel Lesiński

Received on Saturday, 3 March 2012 01:53:29 UTC