Re: new draft trusted-proxy20-00

Hi Yoav,

sorry to be extremely late on answering to your mails
and thanks a lot for all your comments

please see in line

On Jan 13, 2014, at 4:55 PM, Yoav Nir <synp71@live.com> wrote:

> Hi, Salvatore
> 
> Thanks for writing this.  A few comments:
> 
> Section 3.1 has the HTTP proxy indicate its presence by intercepting the ClientHello and returning an error. There are some issue here:
> 
> * An explicit proxy does not have to be on the data path, and in fact
>   it usually isn't.

in the open internet I agree with you,
in the Mobile telecom network usually it is on the data path 
(i.e. the Gi interface between the GGSN and the open internet)

anyway I do believe we should find a solution that is generic enough to work
on all the possible network configuration.

> While MitM proxies have to intercept, clients open
>   connections to explicit proxies, so they're likely to reside in a
>   data-center (sometimes even in the cloud).

explicit proxies residing in data-center have to be explicit configured
so a pac file seems to be a reasonable solution for it

> Blocking HTTP(S) falls to
>   a network firewall. In other words, a MitM proxy usually needs to be
>   co-located with the firewall, but not so for an explicit proxy.

I don't agree with the terminology here
yes an explicit proxy has to be co-locate with the firewall to "block"/analyse HTTPS
however this kind of proxy can also work in a different way that as MitM
I am working on updating the draft to show a possible way of working


> * I don't get how the firewall is supposed to redirect the client to
>   the proxy.

I am clarifying this in the new version of the draft 
a possibility is that you are forced to download a pac file that configure
your browser in proxy mode

> The third paragraph says "The error could for e.g. be
>   sent using the TLS Alert protocol, but this requires registration of
>   a new error type." I didn't understand whether this is what you are
>   recommending (at least for this solution) or whether there are other
>   options.

there are other options… yes
but a TLS Alert is one

> It should be noted that in order for the firewall to be
>   able to send TLS alerts, it has to MitM at least TCP, as the browser
>   thinks it is opening a connection with the server.

that is the idea: acting as a TCP proxy inspecting until the ClientHello message
and then trying to discriminate at that level based on the 
application tag in ALPN

> If we were
>   specifying the Internet from scratch, we could define an ICMP
>   message that can be sent to the browser in response to the TCP-SYN
>   packet. I'm not sure how well that would work, and whether the
>   operating systems that we're using even have APIs to tell the
>   application what the content of the ICMP was, so I guess we're stuck
>   with firewalls impersonating servers at the TCP layer.

I agree that sec ion 4.1 and 4.2 are in the current version of the draft not so clear
and also that maybe the idea described there are a little over engineered
I am trying to simplify the solution and at same time include a mechanism that
explicitly make the user aware of the presence of the proxy in between
and explicitly requires the user consent to have a Forward Proxy in between

Note that the idea is that a Forward Proxy in between would be only be in between
for "http:" uri resources

br
Salvatore 

> 
> Section 4.1 describes tunneling by using the HTTP CONNECT method, but then the connection between the UA and the proxy is described at an HTTPS2 connection, and the proxy seems to have access to the request frames. Specifically, a decryption key is passed in an HTTP2 frame. To add to the confusion, the title of this section is "Tunneling". The CONNECT method does go with the term "Tunneling", but then the TLS session is between the UA and the server, while the proxy only sees TLS records and cannot read any of the HTTP2 frames, which may share a TLS record, or span several TLS records. With tunneling, the proxy does little more than moving packets back and forth.
> 
> The alternative to tunneling, that is sort-of described in section 4.2 is the use of a GET method. In this case the client really opens an HTTPS(2) connection to the proxy, and then sends a GET method for resource "https://server.example.com/resource.html". The server has a totally separate TLS connection with the server and tunnels the requests back and forth. If the proxy can reply to a request from its own cache, it may do so. If it is configured to inspect the content to filter out inappropriate content, it can do that as well. *This* is a trusted proxy. A proxy with tunneling does not need to be trusted any more than the Internet does.
> 
> Lastly, section 4.2 says that the UA "tunnels" all requests towards the same web server in a single connection. In fact, the UA can tunnel all of its requests towards all servers in the world through this connection. Similarly, the proxy could unify the traffic for several UAs into a single connection with the server. This would work for normal servers, but do we know that no servers make any assumptions about requests based on TCP connection?  I know they shouldn't - that's what HTTP cookies are for - but it's possible that some do.
> 
> Yoav
> 
> 
> On 10/1/14 1:51 PM, Salvatore Loreto wrote:
>> Hi there,
>> 
>> we have submitted a new draft with the aim to continue the discussion on
>> explicit and trusted proxy as intermediary of HTTP2S traffic:
>> http://www.ietf.org/internet-drafts/draft-loreto-httpbis-trusted-proxy20-00.txt
>> 
>> 
>> The document proposes a method for an user agent to automatically
>> discover (using the TLS Alert) and configure a proxy via a secure HTTP2.0 session.
>> 
>> Moreover the document also draft two alternative mechanisms that allow
>> the presence of HTTP2.0 secure proxies for TLS protected traffic when an user-agent
>> is requesting an http resource.
>> 
>> br
>> Salvatore
> 
>

Received on Tuesday, 11 February 2014 08:26:34 UTC