- From: Willy Tarreau <w@1wt.eu>
- Date: Tue, 12 May 2015 15:21:06 +0200
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Mark Nottingham <mnot@mnot.net>, Martin Thomson <martin.thomson@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
On Tue, May 12, 2015 at 01:07:58PM +0000, Poul-Henning Kamp wrote: > -------- > In message <20150512082524.GC6738@1wt.eu>, Willy Tarreau writes: > > >Note that if a client supporting an encrypted response payload sets gzip in > >Accept-Encoding, it probably means it's willing to decompress *after* > >decryption, [...] > > That be an information leak. We shouldn't say anything which tells > anybody anything about what the encrypted data means. Good point, which brings back the header fields encryption. Thus maybe as was suggested, if any header is to be encrypted it should be moved to the payload part (mime or so). That said, a correct encryption algorithm would not be weakened by knowing that the first 3 bytes are expected to be 0x1f8b08. > I thinke the order has to be encryption before gzip, and if that > means that people pointlessly gzip AES output, then there is no > more (or less) harm than them gzip'ing JPEGS. It depends. What I remember about was SSL contents deciphered on the SSL gateway and encrypted in the payload only. If these contents were gzipped, they remain in gzip format but encrypted. > >When it comes to caches, I don't know if anything must be done, it could > >even be useful to cache such contents if multiple clients use the same > >key. Maybe pass a vary: referencing the encryption key then, but I could > >be wrong, I'd rather let the experts talk. > > I can see a lot of use cases for that scenairo. (See also my previous > email about why C-E shouldn't be involved.) I do as well which is why I think we must be careful to predict them before it's misused because the use cases were understimated :-) Willy
Received on Tuesday, 12 May 2015 13:21:52 UTC