Re: new version trusted-proxy20 draft

On Feb 19, 2014, at 6:15 AM, Paul Hoffman <paul.hoffman@gmail.com<mailto:paul.hoffman@gmail.com>> wrote:

On Tue, Feb 18, 2014 at 6:02 PM, William Chan (陈智昌) <willchan@chromium.org<mailto: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.

I apologise to have not been so clear in the draft (working against the deadline is always a challenge)
 but yes of course there will be an error

br
Salvatore


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<mailto:pmcmanus@mozilla.com>> wrote:
>
>
>
> On Tue, Feb 18, 2014 at 5:16 AM, Salvatore Loreto
> <salvatore.loreto@ericsson.com<mailto:salvatore.loreto@ericsson.com>> wrote:
>>
>>
>> On Feb 17, 2014, at 4:00 PM, Patrick McManus <pmcmanus@mozilla.com<mailto: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.
>