Re: Proposal: Explicit HTTP2S proxy with any node refusal

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 Wednesday, 27 November 2013 20:59:28 UTC