W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: new version trusted-proxy20 draft

From: Paul Hoffman <paul.hoffman@gmail.com>
Date: Tue, 18 Feb 2014 20:15:05 -0800
Message-ID: <CAPik8yYKevsXB0_B_CK8mw_w2N9vx+URj+-U9VC7i-9VgSnc2g@mail.gmail.com>
To: William Chan (陈智昌) <willchan@chromium.org>
Cc: Patrick McManus <pmcmanus@mozilla.com>, Salvatore Loreto <salvatore.loreto@ericsson.com>, HTTP Working Group <ietf-http-wg@w3.org>, "draft-loreto-httpbis-trusted-proxy20@tools.ietf.org" <draft-loreto-httpbis-trusted-proxy20@tools.ietf.org>, GUS BOURG <gb3635@att.com>
On Tue, Feb 18, 2014 at 6:02 PM, William Chan (陈智昌)

> My first instinct was to agree with Patrick's analysis here. Then I
> looked at the draft in more detail. IIUC, the connection we're talking
> about is the encrypted user-agent<=>forward proxy connection, where
> the forward proxy is authenticated. Even though the connection is
> carrying http:// schemed traffic, the connection to the proxy is fully
> authenticated and I think user agents should show an error page if
> someone MITM'd this connection, even though it only carried http://
> schemed traffic. Did I understand things correctly? Are we talking
> about just the proxy connection here?

The draft is far from clear here, but I would certainly hope that is the
case: if there is an failure in the TLS handshake between the client and
the proxy, *regardless of what caused the connection to the proxy to start
up*, an error would be shown.

> That said, it's not immediately obvious to me why the forward proxy
> needs to have things separated out on a separate connection. Is it
> that you'd like to provide different QoS for http:// and https://
> traffic? If so, I disagree with this on principle. https:// traffic
> should not be discriminated against. I agree with Patrick that it's
> overall better, were a user agent to support http:// schemed traffic
> over HTTP/2/TLS, to serve it on the same connection as https://
> traffic. I'd appreciate a section in the document that explained the
> reasoning behind separating out the connections. Sorry if I'm being
> dense or missed it somewhere, but it isn't obvious to me why this is
> necessary or desirable.


> And furthermore, I should add that I don't really think it's in the
> users' interests to have an intermediary be able to snoop listen in on
> all their https traffic. I don't really see the value for end users in
> standardizing any mechanism for doing this. Is there any?
> On Tue, Feb 18, 2014 at 6:29 AM, Patrick McManus <pmcmanus@mozilla.com>
> wrote:
> >
> >
> >
> > On Tue, Feb 18, 2014 at 5:16 AM, Salvatore Loreto
> > <salvatore.loreto@ericsson.com> wrote:
> >>
> >>
> >> On Feb 17, 2014, at 4:00 PM, Patrick McManus <pmcmanus@mozilla.com>
> wrote:
> >>
> >>
> >>> This has the effect of signaling to an on path observer which
> >>> transactions, in a large stream of them, will not be able to detect a
> >>> interaction. I'm not in favour.
> >>>
> >>>
> >>
> >> The draft proposal to define "h2clr" for http traffic does not make the
> >> environment more prone to stealthy MITMs then just having "h2"
> >>
> >
> >  Assume the traffic has a mix of resources on port 443 using TLS. some
> will
> > insist on strong TLS semantics (i.e. https) and some that will not
> (http).
> > When blocked by an attacker the strong ones throw a visible error and the
> > weak ones do something like fall back to cleartext http/1. The attacker
> does
> > not want to be detected via visible error.
> >
> > If all of those transactions are labeled "h2" then an active attacker
> has to
> > guess which flows can be attacked without being detected. The risk  of
> > getting it wrong is a barrier to the attack. All the better if the
> > transactions are muxxed together into the same TLS connection.
> >
> > Splitting them into 2 connections with 2 different ALPN tokens is pretty
> > much labeling one of them "mess with me". Which is also pretty much the
> > point of your proposal afaict - you're just doing it on behalf of a
> firewall
> > instead of someone installing an illicit fiber tap.
> >
Received on Wednesday, 19 February 2014 04:15:33 UTC

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