WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
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?
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)?