Re: new version trusted-proxy20 draft

On Tue, Feb 18, 2014 at 6:02 PM, William Chan (陈智昌)
<willchan@chromium.org>wrote:

> 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
> MITM
> >>> 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.
> >
>
>