- From: James M Snell <jasnell@gmail.com>
- Date: Tue, 19 Nov 2013 21:14:44 -0800
- To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
- Cc: Roberto Peon <grmocg@gmail.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Tue, Nov 19, 2013 at 9:06 PM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote: > On Tue, Nov 19, 2013 at 08:47:43PM -0800, James M Snell wrote: >> On Tue, Nov 19, 2013 at 8:39 PM, Ilari Liusvaara >> <ilari.liusvaara@elisanet.fi> wrote: >> > >> > How would that work? CONNECT is essentially TCP stream carried within >> > HTTP/2 mux. >> >> CONNECT within HTTP/2 consists of a HEADERS frame followed by any >> number of DATA frames. If, before sending the CONNECT we negotiate a >> key agreement with the authority/origin, every DATA frame in the >> CONNECT stream would be encrypted in accordance with the agreement. An >> intermediary would be less able to inspect the DATA frame payload to >> see what's going on inside. > > CONNECT isn't end-to-end. The CONNECT method itself is not, but the payload of the DATA frames in a CONNECT stream are. Specifically, The payload of any DATA frames sent by the client are transmitted by the proxy to the TCP server; data received from the TCP server is assembled into DATA frames by the proxy. So the client would encrypt that data and pass it along via the intermediary, which would just see an opaque blob of bytes. All that's required is some way of indicating which negotiated key is being used (thus the reason I have the first four bytes of every data frame payload specify the key identifier). And yes, I'm fully aware that there are still unanswered questions that would need to be worked out. Like I said from the beginning, this is an *experimental* idea :-) I'm no where near close to having this thing proven - James > > -Ilari
Received on Wednesday, 20 November 2013 05:15:34 UTC