- From: James M Snell <jasnell@gmail.com>
- Date: Tue, 19 Nov 2013 20:47:43 -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 8:39 PM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote: > On Tue, Nov 19, 2013 at 05:52:57PM -0800, James M Snell wrote: > >> Also, keep in the mind the CONNECT tunnel option. One could negotiate >> an agreement and use that along with a CONNECT tunnel. Once that's >> done, any traffic that passes back and forth within that tunnel would >> be protected, limiting potential leakage. If we add incremental >> integrity checking to the picture, this becomes more reliable (albeit >> more complex as well). > > 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. - James > -Ilari
Received on Wednesday, 20 November 2013 04:48:31 UTC