- From: Manger, James H <James.H.Manger@team.telstra.com>
- Date: Tue, 6 Mar 2012 15:07:31 +1100
- To: Ian Hickson <ian@hixie.ch>, URI <uri@w3.org>, HTTP Working Group <ietf-http-wg@w3.org>
RE: http+aes <http://dev.w3.org/html5/spec/iana.html#http-aes-scheme> A URL scheme that combines an address plus key material for securing the content at that address has some merit. http+aes, however, has some specific flaws: 1. Encryption without integrity (as http+aes delivers) is almost worthless. It rarely delivers the security that you expect. The untrusted CDN can make all sorts of modifications: truncating the content; toggling any bits of the content; etc. Many modifications will cause errors that depend on the content. Watch which errors occur from which modifications and you learn the content. These sorts of practical attacks have occurred numerous times (often with CBC mode, but decrypting without checking integrity is the root cause). 2. Hardwiring 1 specific algorithm (AES), 1 mode (counter), and 3 key lengths (128-bit, 192-bit, & 256-bit) is very poor practise. We need algorithm agility to cope with advances in crypto. 3. What happens if the CDN returns an HTTP redirect? Is the content after following the redirect supposed to be encrypted or not? Does it matter if the redirect goes to a different origin? HTTP errors (with a response body) will, presumably, not be encrypted. I hope a 500 error with a response body containing javascript cannot get the http+aes URL from, say, window.location. 4. I am not sure what an http+aes URL means to the user-agent. Obviously if the user-agent gets an encrypted body it can decrypt it with the given key. Should it reject a response with a cleartext body? Probably not as http+aes was not offering any integrity or authentication anyway. Does an http+aes URL have the same "origin" as an http URL (for same-origin purposes, the Origin HTTP header etc)? -- James Manger
Received on Tuesday, 6 March 2012 04:09:41 UTC