Re: new draft trusted-proxy20-00

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 21:35:11 UTC