Re: new draft trusted-proxy20-00

[Salvatore Loreto <[e-mail]>]

On Jan 15, 2014, at 11: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.

exactly what we are trying to achieve in the modified proposal we are working on for the new version of the draft

/Salvatore

> 
> 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
>>> 
>>> 
>>> 
>> 
>