Re: Proposal: Explicit HTTP2S proxy with any node refusal

I agree and I think we need to come up with a way for the third handshake
to piggyback on the second.

For instance, does the browser need to send the ClientHello twice?

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