Re: new draft trusted-proxy20-00

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" <bizzbyster@gmail.com>
To: "Adrien de Croy" <adrien@qbik.com>
Cc: "Yoav Nir" <synp71@live.com>; "Salvatore Loreto" 
<salvatore.loreto@ericsson.com>; "HTTP Working Group" 
<ietf-http-wg@w3.org>; "Robert Skog" <robert.skog@ericsson.com>; "Hans 
Spaak" <hans.spaak@ericsson.com>; "John Mattsson" 
<john.mattsson@ericsson.com>
Sent: 16/01/2014 11:47:49
Subject: Re: new draft trusted-proxy20-00

>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 <adrien@qbik.com> 
>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"
>>
>>  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" <bizzbyster@gmail.com>
>>  To: "Yoav Nir" <synp71@live.com>
>>  Cc: "Salvatore Loreto" <salvatore.loreto@ericsson.com>; "HTTP Working 
>>Group"
>>  <ietf-http-wg@w3.org>; "Robert Skog" <robert.skog@ericsson.com>; 
>>"Hans
>>  Spaak" <hans.spaak@ericsson.com>; "John Mattsson"
>>  <john.mattsson@ericsson.com>
>>  Sent: 16/01/2014 07:31:03
>>  Subject: Re: new draft trusted-proxy20-00
>>
>>>  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 <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 22:53:16 UTC