- From: Yoav Nir <ynir@checkpoint.com>
- Date: Fri, 11 Jan 2013 20:04:30 +0000
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
On Jan 11, 2013, at 9:20 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > -------- > In message <CAKRe7JHidJN9rnp9fM_7aevR9opZ7P4GnMT+2C3tdoFqLg6ShQ@mail.gmail.com> > , Ilya Grigorik writes: > >> How does this impact the "long term reality of HTTP/2.0"? > > HTTP/2.0 should be designed so that such intrusions of the "end-to-end > argument" does not cause more than the minimally necessary loss of > security. Define "minimally necessary". The issue described in the link is described as a MitM attack. But that's misleading. The browser is not the victim here, but a willing participant. I think the term "main in the browser" is more appropriate. And I don't think you can ever get a protocol specification to overcome your browser participating in an attack. With real MitM attacks, the browser detects the attack. You get the warning screen about untrusted signers. This gives the browser (and by extension, the user) a choice of accepting the decrypting proxy, or avoiding use of the browser as long as network conditions are such. An improvement would be to give the server the same choice, but I don't see how that can be done for servers that do not require client authentication. Anyway, I don't see how HTTP/2 could do any better than that without becoming some kind of cross-layer monstrosity. Yoav
Received on Friday, 11 January 2013 20:05:01 UTC