- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Tue, 12 May 2015 13:07:58 +0000
- To: Willy Tarreau <w@1wt.eu>
- 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>
-------- 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. 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. >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.) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Tuesday, 12 May 2015 13:08:22 UTC