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

Re: new version trusted-proxy20 draft

From: 陈智昌 <willchan@chromium.org>
Date: Wed, 19 Feb 2014 10:20:48 -0800
Message-ID: <CAA4WUYjZVEp+Wr=XTVqyT8hAhQ9tUL26QDZxCEzMdXUnZwvQ-Q@mail.gmail.com>
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: 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>
Sorry, I was confused. Indeed, I agree with you that, were we to send
http schemed requests over a HTTP/2/TLS connection, we should not
separate the http schemed requests and https schemed requests into
separate connections that are identifiable via ALPN.

On Wed, Feb 19, 2014 at 9:12 AM, Patrick McManus <pmcmanus@mozilla.com> wrote:
> I apologize I was AFK for a couple days.
> On Tue, Feb 18, 2014 at 9: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.
> There seems to be some confusion. This reply makes it sound like I was
> talking about the connection between the UA and the proxy - which I did not
> mean to. I am talking about the connection between the UA and the origin
> server prior to proxy detection - perhaps in cases where there is no proxy
> present.
> In particular am talking about section 3.2.. which envisions a connection to
> the origin over TLS for an http URI. The proposal suggests that the ALPN
> token of h2clr be used to distinguish this connection from ones carrying
> https URIs. The IP destination address of the request is that of the origin.
> According to the description, a proxy hijacks that TCP connection based on
> the ALPN token before forwarding the Client Hello and inserts a TLS Alert on
> the data stream with the src IP of the origin.
> The user agent is expected to fallback to HTTP/1 in cleartext and repeat the
> query to the origin. According to the draft, the proxy again hijacks that
> TCP session and replies with a HTTP/1 redirect to an authenticated proxy
> credential page on https://. That page helps you configure your UA so that
> future queries are addressed to the proxy instead of to the origin based on
> PKI trust.
> No error page is described and there is an explicit dependency on the
> fallback to cleartext when the original transaction is blocked.
> A major concern here is that a traditional MITM attacker is pretty much
> inseperable from the proxy envisioned by the draft. i.e. in the absence of a
> proxy the MITM sees "h2clr" and forces a downgrade via an injected (and
> unauthenticated) Alert and the UA repeats the transaction in cleartext. MITM
> wins.
> The proposal to use h2clr makes this problem more severe than it would
> normally be because the http transactions can no longer mix themselves into
> the https stream unobtrusively. Thus they are identifying to the attacker
> that they can be messed with and that's an advantage to the attacker who
> would ordinarily run the risk of getting an error when they injected the TLS
> Alert.
> I'm trying not to comment directly on the merits of the overall proxy
> proposal other than the change it is proposing to the core http/2 protocol.
> So I'm opposed to the change in ALPN tokens on these grounds as well as the
> efficiency grounds of requiring the use of more connections to carry
> multiple schemes via the same route.
Received on Wednesday, 19 February 2014 18:21:15 UTC

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