Re: Proposal: Explicit HTTP2S proxy with any node refusal

Hi Adrien,

I just wanted to revisit this to clarify that we are only adding one
TLS 3 way between proxy and server, for the point to point TLS session
between them -- the others are the same as today's CONNECT. If we're
talking about a forward proxy and the high latency network is between
proxy and server, then this is a big downside I agree.

I wonder if the point-to-point TLS 3 way handshake between proxy and
server can be negotiated simultaneously with the end-to-end TLS 3 way
handshake somehow. This could no doubt be accomplished via changes to
the underlying TLS protocol, but that seems like an even steeper hill
to climb than an HTTP-level trusted proxy.

Another alternative is that split proxies could be deployed to address
the high latency segment. So, for instance, a cache deployed in New
Zealand to optimize HTTP 1.x traffic to/from North America could be
augmented with a second partner cache deployed in North America. All
traffic between the partners is encrypted via a a persistent TLS
session and the extra proxy to server TLS negotiation would then be
conducted over the presumably lower latency network between North
American cache and server. In a nutshell, a split proxy can help
alleviate the extra proxy-server round trips incurred by this Any Node
Refusal scheme.

Thanks,

Peter

On Wed, Nov 27, 2013 at 3:58 PM, Adrien de Croy <adrien@qbik.com> wrote:
> my main issue wasn't so much the client to proxy TLS 3 way, but the proxy to
> server
>
> TCP 3 way handshake
> TLS 3 way handshake
> another TLS 3 way handshake.
>
> That's a lot of RTs.  Sprinkly 300ms latency on each RT and you have a
> problem.
>
>
> Adrien
>
> ------ Original Message ------
> From: "Nicolas Mailhot" <nicolas.mailhot@laposte.net>
> To: "Adrien de Croy" <adrien@qbik.com>
> Cc: "Peter Lepeska" <bizzbyster@gmail.com>; "ietf-http-wg@w3.org"
> <ietf-http-wg@w3.org>
> Sent: 28/11/2013 9:53:08 a.m.
> Subject: Re: Proposal: Explicit HTTP2S proxy with any node refusal
>>
>>
>> Le Mer 27 novembre 2013 00:40, Adrien de Croy a écrit :
>>>
>>>
>>>  fundamentally this proposes a compromise between level of trust of the
>>>  proxy vs performance.
>>>
>>>  Since we don't trust the proxy not to alter content, we have to endure
>>>  extra round trips to set up the second layer of TLS
>>
>>
>> Consider that a browser is likely to establish a tls channel to the
>> proxies active on his network as soon as the user starts browsing, so yes
>> there will be a penalty for the first objects but the next ones won't see
>> the difference (and properly designed web sites will benefit from the
>> caching at the proxy layer.
>>
>> I said proxies because we, for example, run a high-availability setup and
>> each browser gets two proxies on two different physical sites at startup
>> (much more reliable to have browsers failover or load-balance as they wish
>> depending on network conditions)
>>
>> Regards
>>
>> --
>> Nicolas Mailhot
>>
>

Received on Friday, 17 January 2014 17:52:55 UTC