Re: new version trusted-proxy20 draft

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.