Re: new draft trusted-proxy20-00

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. 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). 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 get how the firewall is supposed to redirect the client to
    the proxy. 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. 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. 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.

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