Re: new draft trusted-proxy20-00

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.

Yoav,

I think the draft just uses the term "tunneling" in a broader way, to
also mean when the proxy can decrpyt and inspect the end-to-end
traffic. Both of the above ideas are described in Roberto's draft and
they are roughly 1) trusted proxy is able to view traffic from a
secure session between UA and server b/c it has a decryption key, and
2) trusted proxy is able to view traffic b/c only point-to-point
secure sessions are active and so browser sends GET
http://contentserver/index.html to the proxy over their point-to-point
TLS session.

As much as I'd like to see a trusted proxy architecture gain momentum,
I can't see either of these ideas passing a security review for
reasons that have been discussed on this list in the past. For me, the
need to export and transmit a session key is a showstopper for #1 and
#2 lacks any way for the user to perform its own web server
authentication and in general to inspect the quality of the encryption
of the web server it is trusting. In some ways, it requires even more
complete transitive trust than MITMs typically deliver today.

For #2 to work, the browser and proxy need to act more like the split
browser in the Amazon Silk architecture. Where essentially some of the
work typically done in the browser is performed in the proxy. In this
case, the database of trusted CAs would need to be in the proxy and
the user would need a way to view that database via the browser.
Instead of having two CA databases with the problems of transitive
trust, the tightly coupled browser-proxy, like the Silk split browser,
would have just one CA database implemented at the proxy. This type of
approach might work for some of the user stories described here --
https://github.com/http2/http2-spec/wiki/Proxy-User-Stories.

Peter


On Mon, Jan 13, 2014 at 9:55 AM, 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. 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
>
>
>

Received on Wednesday, 15 January 2014 18:59:51 UTC