W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Response to HTTP2 expresions of interest

From: Tim Bray <tbray@textuality.com>
Date: Fri, 13 Jul 2012 20:21:03 -0700
Message-ID: <CAHBU6iu8n_RV+oaJy=BAR5PXi1TGqvurpS14aH_4uwFLVf9QuA@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: James M Snell <jasnell@gmail.com>, Phillip Hallam-Baker <hallam@gmail.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On Fri, Jul 13, 2012 at 11:21 AM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote:

> TLS communication today already have an envelope consisting of
> IP# + TCP port numbers, and unless your adversary is totally
> incompetent, he also has the DNS lookup that gave you that IP#.
> QED: Putting the "Host:" in the HTTP envelope does not leak any
> information your adversary doesn't already have or can guess.

Thatís just not true.  There are lots of ways to get to a particular origin
server, and I would think that for a malicious person in the middle, the
Host header would be more interesting than the ostensible IP address.  On
the other hand, I do understand why a payload-oblivious load balancer would
need to see that header.  It is simply the case that we have two objectives
which are apparently in conflict. No, I donít have a solution (or even a
strong opinion, yet, although Iím inclined to err on the side of protecting
user privacy at the expense of almost all else).  -Tim

> Even if we stopped here, it would be a major benefit over TLS
> in terms of enabling websites to roll out protection for their
> customers.
> To make it better, we need to add a session identifier, but today
> we pretend HTTP is stateless so we don't have one (so people
> hack it with cookies).
> Finally, to do what people do today we would need to include the
> URI, but that is by far the most troublesome of the three fields.
> I belive, but it should be seriously investigated, that if we add
> a session-concept to HTTP2, the envelope would just need to be Host:
> + session-nonce.
> In difference from TLS, that would allow us to mix protected and
> unprotected traffic on the same TCP connection, thus avoiding
> the extra TCP for protection upgrade, and making life much
> easier and efficient for proxies.
> It also means that you do not need to put your certificate on
> the HTTP router/load-balancer, but can put it on the specific
> webservers which host the protected stuff.
> SSL/TLS was a quick hack to protect HTTP, one of the far too
> many quick hacks in HTTP world.  We should try to eliminate
> them.
> --
> 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 Saturday, 14 July 2012 03:21:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:02 UTC