Subject: new draft trusted-proxy20-00

From: Salvatore Loreto <[email-masked]>
Date: Fri, 10 Jan 2014 11:51:34 +0000

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

---

From: Yoav Nir <[email-masked]>
Date: Mon, 13 Jan 2014 16:55:28 +0200

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

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Mon, 13 Jan 2014 21:00:14 +0100

Le Lun 13 janvier 2014 15:55, Yoav Nir a écrit :
> This would work for normal

I sure hope they don't, I see Firefox users load-balancing between the two
available datacenter paths here (two proxies provided in the pacfile)

OTOH we do diable automatique load balancing on the server proxies, it
seems enterprisey web services are not so relisient.

-- 
Nicolas Mailhot

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 13 Jan 2014 20:48:39 +0000

sure they do.

connection-oriented auth.

Adrien

------ Original Message ------
From: "Nicolas Mailhot" <[email-masked]>
To: "Yoav Nir" <[email-masked]>
Cc: "Salvatore Loreto" <[email-masked]>; "HTTP Working 
Group" <[email-masked]>; "Robert Skog" <[email-masked]>; 
"Hans Spaak" <[email-masked]>; "John Mattsson" 
<[email-masked]>
Sent: 14/01/2014 09:00:14
Subject: Re: new draft trusted-proxy20-00

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 14 Jan 2014 10:28:38 +0100

> connection-oriented auth.

Well, in practice they don't for web sites (not web services). I have the
traffic to prove it :p Given that it's the majority of the traffic, I
don't see the problem in making it an http2 assumption.

-- 
Nicolas Mailhot

---

From: Peter Lepeska <[email-masked]>
Date: Wed, 15 Jan 2014 13:31:03 -0500

More questions:

"The proxy intercept and does not forward the ClientHello message,
   instead it returns a signed error message ("Here be proxies")
   containing a certificate identifying the proxy. "

What happens if the client decides that it does not trust the proxy?
Does it send a new ClientHello that the proxy forwards? How does the
proxy distinguish between the first ClientHello that it does not
forward and the second ClientHello that it does forward?

Or, on the other hand, is trusting the proxy required to use the
network in the use case for this new mechanism?

Thanks,

Peter

But taking a step back, it seems like you are proposing a way for a
proxy to advertise its presence for HTTPS connections. D

On Mon, Jan 13, 2014 at 9:55 AM, Yoav Nir <[email-masked]> wrote:
> 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
>
>
>

---

From: Peter Lepeska <[email-masked]>
Date: Wed, 15 Jan 2014 13:59:23 -0500

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

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 15 Jan 2014 21:34:39 +0000

What I would expect in this mechanism, is that you wouldn't get the 
Client Hello blocked unless the proxy was asserting that it must be 
used.

Otherwise you'd need 2 different types of response - 1 "you must use 
me", or 2 "you can try again and I won't block it next time honest"

In case 1, the user gets to choose between

1. I will trust the proxy; or
2. I will not use the internet

which is a perfectly reasonable choice IMO.  Just like the EULA page on 
many a software installer.

Cheers

Adrien

------ Original Message ------
From: "Peter Lepeska" <[email-masked]>
To: "Yoav Nir" <[email-masked]>
Cc: "Salvatore Loreto" <[email-masked]>; "HTTP Working 
Sent: 16/01/2014 07:31:03

>>then
>>>  discover (using the TLS Alert) and configure a proxy via a secure 
>>>HTTP2.0
>>>  session.
>>>
>>>  the presence of HTTP2.0 secure proxies for TLS protected traffic 
>>>when an
>>>  user-agent

---

From: Peter Lepeska <[email-masked]>
Date: Wed, 15 Jan 2014 17:47:49 -0500

Okay. In your case #2, maybe the second ClientHello will need a flag
that says "I know you are there proxy but I don't want use you" so
that distinguishing between the first and second type of ClientHello
is straightforward.

Peter

On Wed, Jan 15, 2014 at 4:34 PM, Adrien de Croy <[email-masked]> wrote:
>
> What I would expect in this mechanism, is that you wouldn't get the Client
> Hello blocked unless the proxy was asserting that it must be used.
>
> Otherwise you'd need 2 different types of response - 1 "you must use me", or
> 2 "you can try again and I won't block it next time honest"
>
> which is a perfectly reasonable choice IMO.  Just like the EULA page on many
> a software installer.
>
> Cheers
>
> Adrien
>
>
> Cc: "Salvatore Loreto" <[email-masked]>; "HTTP Working Group"
> <[email-masked]>; "Robert Skog" <[email-masked]>; "Hans
> Spaak" <[email-masked]>; "John Mattsson"
>>> is
>>> same
>>>>  the presence of HTTP2.0 secure proxies for TLS protected traffic when
>>>> an
>>>>  user-agent

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 15 Jan 2014 22:52:47 +0000

Actually there's maybe another option that wouldn't require changing TLS 
or HTTP.

it would need to go down a layer to TCP though.

In intercepting proxies, the first thing is the TCP 3 way handshake.  If 
this could be extended (TCP option) then we could achieve the same 
result, but use it for any TCP-based protocol not just http and TLS.

I'm sure this idea will go down like a lead balloon, but there are less 
useful TCP options that have been standardised (and largely ignored) I'm 
pretty sure.

------ Original Message ------
From: "Peter Lepeska" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Yoav Nir" <[email-masked]>; "Salvatore Loreto" 
<[email-masked]>; "HTTP Working Group" 
<[email-masked]>; "Robert Skog" <[email-masked]>; "Hans 
Spaak" <[email-masked]>; "John Mattsson" 
<[email-masked]>
Sent: 16/01/2014 11:47:49
Subject: Re: new draft trusted-proxy20-00

>>Client
>>me", or
>>Group"
>>>>   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
>>>>   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.
>>>>   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
>>>>   connection? I know they shouldn't - that's what HTTP cookies are 
>>>>for -
>>>>  but
>>>>>   we have submitted a new draft with the aim to continue the 
>>>>>discussion
>>>>>  on
>>>>>when