W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: Proposal: Explicit HTTP2S proxy with any node refusal

From: Peter Lepeska <bizzbyster@gmail.com>
Date: Fri, 17 Jan 2014 12:52:28 -0500
Message-ID: <CANmPAYEY=_BWKsEB4jqm67hZ+sTf8nOpfGx7jJ=wnyz4J-T4Jg@mail.gmail.com>
To: Adrien de Croy <adrien@qbik.com>
Cc: Nicolas Mailhot <nicolas.mailhot@laposte.net>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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.



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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:23 UTC