Re: new draft trusted-proxy20-00

[Peter Lepeska <[e-mail]>]

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 <[e-mail]> 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" <[e-mail]>
> To: "Yoav Nir" <[e-mail]>
> Cc: "Salvatore Loreto" <[e-mail]>; "HTTP Working Group"
> <[e-mail]>; "Robert Skog" <[e-mail]>; "Hans
> Spaak" <[e-mail]>; "John Mattsson"
> <[e-mail]>
> 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 <[e-mail]> 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
>>>
>>>
>>>
>>>
>>
>