Re: new version trusted-proxy20 draft


On Feb 19, 2014, at 3:02 AM, 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. Even though the connection is
> carrying http:// schemed traffic, the connection to the proxy is fully
> authenticated

yes exactly the connection between the UA and 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?

yes

> 
> 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?

No, there isn't any QoS reason behind 


> If so, I disagree with this on principle. https:// traffic
> should not be discriminated against.

 it is not the intention of our draft really!

> 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.

the main is to leave  the HTTPS flows completely untouched, to make crystal clear that the Proxy
won't do anything for those flows.
the proposal also minimise the change in the specification;
and as we are also playing with some code we thought it was a solution that could be straightforward and easy to implement

anyway 
point taken, I will add an explanatory section on the reason to differentiate the HTTPS from the HTTP flow … in the next version
if we will still be convinced that is the right solution


> 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?

and we are not proposing that
secure proxy that is described in the draft won't do that


/Sal

> 
> On Tue, Feb 18, 2014 at 6:29 AM, Patrick McManus <pmcmanus@mozilla.com> wrote:
>> 
>> 
>> 
>> 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 Wednesday, 19 February 2014 20:46:54 UTC