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

Re: new version trusted-proxy20 draft

From: Patrick McManus <pmcmanus@mozilla.com>
Date: Tue, 18 Feb 2014 09:29:31 -0500
Message-ID: <CAOdDvNrp6AsnnMAqbxT5Bs+agNTeadsZw+2gMsjUXPVvnpBDdg@mail.gmail.com>
To: Salvatore Loreto <salvatore.loreto@ericsson.com>
Cc: 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 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.
Received on Tuesday, 18 February 2014 14:30:06 UTC

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