Re: Do we kill the "Host:" header in HTTP/2 ?

Nico Williams <nico@...> writes:

> 
> On Wed, Jan 30, 2013 at 3:31 PM, Adrien W. de Croy <adrien@...> wrote:
> > from a proxy POV, it's very useful, nay vital that we can tell the
> > difference between a request that a client thinks it is sending to a proxy,
> > vs a request the client thinks it is sending to a server.
> >
> > [...]
> > In fact for authentication, I would extend it to allow for the definition of
> > the target of the auth.  If you have a request going through a chain, and
> > several links require auth from the client, there's currently no way to do
> > it safely.
> 
> There are separate headers for authentication to proxies.

The current separate headers for authentication to proxies are a miserable
failure which is impossible to use in all but the simplest cases:

1. they only work with a single intermediary. Want to chain networks with
authentification gateways?  No can do. Someone forgot that the Internet was
built by interconnecting distinct networks, and that those networks are not
freely accessible except for entertainment junkies at home.

2. they are insecure: you can't send them securely to the intermediary without
piggy-backing on the main transport crypto. Want to authenticate to the proxy to
access an http site ? Best hope every link between the user and the intermediary
is secure, because everyone will see your credentials. Want to access an https
web site? Need MITM by the intermediary to be able to read your damn proxy
credentials

3. since web clients do not really have a way to send them to the right network
node at the right time many just spread-fire proxy auth on every request in the
hope they'll get picked up whenever necessary. Including when they are not using
a proxified link (so it works all the time, at the expense of giving proxy
secrets to every random web site).

HTTP1 proxy auth is too broken to be rescued. It should be taken in the backyard
and quietly shot in the head. I do hope HTTP2 will make things better.

(HTTP 511 is a bit better, but relies on js support in the web clients)

-- 
Nicolas Mailhot

Received on Friday, 22 February 2013 18:20:59 UTC