- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Tue, 12 May 2015 18:50:10 +0000
- To: Willy Tarreau <w@1wt.eu>
- cc: Amos Jeffries <squid3@treenet.co.nz>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Mark Nottingham <mnot@mnot.net>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
-------- In message <20150512184635.GL6738@1wt.eu>, Willy Tarreau writes: >> We have to decide precisly how far that goes however, does an plaintext >> 403 response arrive as an encrypted 200 response which only reveal its >> true colors on decryption ? > >I'd rather not start to play with status nor hop-by-hop headers. But on >the other hand, if some headers have to be encrypted even when there's no >contents, you don't want to return a 204/304 implying that content-length >can be ignored and return data after it :-/ > >And a 304 in response to a HEAD request must not reveal the plaintext >headers that would have been encrypted in response to the equivalent >GET request if it is assumed that these ones can reveal sensitive info. > >I'm sorry I haven't read the proposal yet so maybe I'm talking about things >that are already covered, thus I'll rather stop speculating. They are not. >Except that "gzip, aesbla" cannot happen since whatever appears before >"aesbla" would have been moved into the encrypted body. s/would/SHOULD/ There's no guarantee against people doing stupid things. >> The fact that encryption needs to care about metadata means that it >> is not really a "Content-Encoding" but rather a "Message-Encoding". > >That's a possibility as well, though I'm not convinced that it brings >anything beyond C-E above. I think it would bring clarity. -- 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 18:50:36 UTC