Re: http+aes

On Mon, 5 Mar 2012, Willy Tarreau wrote:
> 
> I wouldn't go to such extremities, but at least I think that we're just 
> facing a layering violation. Only the contents have to be encrypted so 
> that the caches cannot use them, while the transport remains unchanged. 
> So a new scheme is not appropriate for this, a Content-Encoding would be 
> much better. User agents would be configured to know that content- 
> encoding XYZ requires a deciphering key whose ID is presented in the 
> header itself and should have been retrieved via another channel.
> 
> Example :
>     Content-Encoding: aes-ctr-128; keyid=0x34751806
>     Cache-control: no-transform

This would require changes at the intermediaries. It would also require a 
mechanism to link keys to IDs, which is non-trivial given the same-origin 
policy, multiple browsing contexts, subresources, etc.


> This has the benefit of working out-of-the-box without affecting 
> existing intermediary components.

It would seem to me to require slightly more effort than the scheme 
approach on this front.


(We did actually consider something like this.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 5 March 2012 23:29:40 UTC