Re: new version trusted-proxy20 draft

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