- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Tue, 12 May 2015 13:48:17 +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 <20150512132106.GG6738@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). It's very simple: You have an envelope everybody can see (the headers) and you have the content (the body). Anything you want to keep secret goes in the body. >That said, a correct encryption algorithm would not be weakened >by knowing that the first 3 bytes are expected to be 0x1f8b08. Which is why really good crypt always has initial and trailing non-sense. And you non-sense had better be good: http://en.wikipedia.org/wiki/The_world_wonders -- 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:48:41 UTC