Subject: Proposal: Explicit HTTP2S proxy with any node refusal

From: Peter Lepeska <[email-masked]>
Date: Tue, 26 Nov 2013 17:29:46 -0500

*Problem statement*:

As Mark, Roberto, and others have argued in multiple Internet Drafts, an
explicit, trusted proxy is preferable to a transparent MITM proxy as
intermediary of HTTP2S traffic (HTTP2 over TLS). One problem in developing
a standard for an explicit, trusted proxy is the process by which a proxy
establishes trust. We don't try to tackle that problem here but believe
that it should be *no easier* than the current process by which MITM
proxies establish trust, which is to install a CA certificate into the
browser's certificate database. So, for instance, one possibility is that
the browser will have a "trusted proxy partition" in its certificate
database and a proxy will only be trusted if its certificate is installed
there. Again, this problem is not solved here.

The harder problems in designing a standard for explicit trusted proxies
are 1) the need for message authentication and integrity, meaning the
browser and server can be confident that the proxy has not tampered with
the data and 2) any node refusal, by which I mean that all actors (browser,
proxy, and server) should both express their intentions and be able to
refuse participation on a per object basis. Three scenarios illustrate the
issue of any node refusal:

1)    Web server says no: A cache (or optimizing proxy) improves end user
response times and network utilization. A user will often elect to trust
this proxy, allowing it to view HTTP2S traffic in the clear, in order to
receive the benefit of the optimization. Many content owners will also
allow this, especially when serving publicly accessible content. However,
some content owners (financial institutions, for instance) may not ever
want to allow a proxy to view traffic in the clear, even if the end user
allowed it.

2)    Proxy says no: Enterprise anti-malware middleboxes do not want to
allow any traffic to pass into or out of the enterprise that cannot be
examined. In this case, a proxy wants to be able to inform the web server
that it will not pass traffic on to the end user that it cannot see.

3)    User/Admin says no: Of course, the obvious scenario is where the user
says no. In this case, we have no trusted proxy.

In order for #1 to be true, allowing a web server to always say no, the
proxy must not be able to run in stealth mode. In order for #2 to be true,
the proxy server must be able to pass an indicator to the web server that
it requires the ability to see all traffic.

*Solution*:

The ideas in James’ Internet Draft Intra-connection
Negotiation<http://www.ietf.org/internet-drafts/draft-snell-httpbis-keynego-01.txt>
create
an opportunity for addressing these two problems. The proposed solution
consists of a) requiring trusted proxies to have their own point-to-point
HTTP2S session with the browser when processing traffic from an HTTP2S
content server and b) establishing an intra-connection, end-to-end, TLS
session using a NULL cipher (no encrypting but still authenticating and
data integrity checking) between browser and web server and using it to
send traffic through a trusted proxy. In this case, the traffic over the
air is encrypted by the point-to-point TLS sessions, while still being
viewable by the proxy, and, at the same time, the browser and web server
can authenticate and validate the integrity of the data and any node can
refuse participation.

The following diagram illustrates the idea:

   Browser
Proxy                                       Server

      |
|                                            |

      |
    |                                            |

      | 1)Establish HTTP2S (HTTP2 over TLS) session
|                                            |

|<------------------------------------------->|
|

      |
|                                            |

      | 2)CLIENT_HELLO over HTTP2S
|                                            |

      |============================================>|
                                |

      |
|                                            |

      |                                             |      3)Establish
HTTP2S session            |

      |
                            |<------------------------------------------>|

      |
|                                            |

      |                                             |      4)Forward
CLIENT_HELLO over HTTP2S    |

      |
|===========================================>|

      |                                             |
                                       |

      |                                             |      5)SERVER_HELLO
over HTTP2S            |

      |
|<===========================================|

      |
                                   |
|

      | 6)Forward SERVER_HELLO over HTTP2S
|                                            |

      |<============================================|
                      |

      |
|                                            |

      |
|                                            |

      | 7)Complete TLS negotiation, specifying a NULL cipher, across two
HTTP2S sessions         |

|<========================================================================================>|

      |
|                                            |

      |
|                                            |

      |
|                                            |

      | 8)Unencrypted HTTP2 traffic includes MACs for auth and integrity
validation              |

|<========================================================================================>|

Note: the “===” lines indicate a message sent over the Intra-Connection
HTTPS stream, so these are over HTTP2, over the point-to-point TLS
sessions, but they travel end-to-end between browser and server.

Because the browser receives the web browser’s certificate in the
SERVER_HELLO in step 6, it will be able to authenticate the server the same
as it would if the trusted proxy were not present. This removes the problem
of transitive trust caused by MITM proxies. One can imagine the browser
displaying a double lock to indicate that both the proxy and the content
server have certificates that have been authenticated – of course the proxy
needs an additional layer of validation but again we will not go into that
here. The important point is that the proxy is not able to view the traffic
unless the browser trusts it and also unless the browser itself has
authenticated the web server’s cert with its own database of CAs.

Message integrity and authentication between browser and web server prevent
the proxy from operating in stealth mode, where its presence is
undetectable by the web server. The web server can thus refuse to take part
in the trusted proxy session on a per object basis. For instance, requests
for the logo of a financial institution might be allowed to be viewed by a
proxy, but requests for sensitive financial information might be refused. This
is what really separates the proposal from simply standardizing MITM
because it means the web server will always be aware of the presence of the
proxy and because, if it decides to, it can say no. I think this is a
powerful feature and one that legitimate middleboxes should also be in
favor of, as it allows them to express their intention in an above board
way (I would like to optimize this traffic or I must see this traffic in
order to scan it for malware) and to be distinguished from rogue MITMs.

Additionally, the browser will always know when an object was manufactured
by the proxy and it can decide whether or not it wants to use it. For
instance, a proxy might send the browser a cached copy of an object the
browser requested. This cached copy will not contain the MAC proving that
it was generated by the web server so the browser will need to make the
decision whether or not to use this object. Again, in many cases the
browser will agree to because it provides a benefit to the end user.

Lastly, and this is not illustrated in the above drawing, the proxy can
flag the TLS data frames it uploads to the web server to indicate whether
or not it will allow encrypted responses. If not, as might be the case for
a security, malware-detecting appliance, then the web server can decide
whether or not it wants to send the data in a way that the proxy can see.
And, if not, then the user can be messaged that the site is not viewable
with appropriate messaging.

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 26 Nov 2013 23:40:07 +0000

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

So the question is, are we trusting the proxy or not?  Sounds like not 
really.

I can see situations where pressure comes to bear on middleware vendors 
to MITM the second layer so that they can alter content.  So I think we 
need to think long and hard before deciding to prohibit that at this 
stage.

I agree the justification for doing this would be greatly reduced 
compared to the current justification for MITM.

Maybe there's another way to get message integrity without incurring 
another TLS 3 way.

Adrien

------ Original Message ------
From: "Peter Lepeska" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 27/11/2013 11:29:46 a.m.
Subject: Proposal: Explicit HTTP2S proxy with any node refusal
>Problem statement:
>
>As Mark, Roberto, and others have argued in multiple Internet Drafts, 
>an explicit, trusted proxy is preferable to a transparent MITM proxy as 
>intermediary of HTTP2S traffic (HTTP2 over TLS). One problem in 
>developing a standard for an explicit, trusted proxy is the process by 
>which a proxy establishes trust. We don't try to tackle that problem 
>here but believe that it should be no easier than the current process 
>by which MITM proxies establish trust, which is to install a CA 
>certificate into the browser's certificate database. So, for instance, 
>one possibility is that the browser will have a "trusted proxy 
>partition" in its certificate database and a proxy will only be trusted 
>if its certificate is installed there. Again, this problem is not 
>solved here.
>
>
>
>The harder problems in designing a standard for explicit trusted 
>proxies are 1) the need for message authentication and integrity, 
>meaning the browser and server can be confident that the proxy has not 
>tampered with the data and 2) any node refusal, by which I mean that 
>all actors (browser, proxy, and server) should both express their 
>intentions and be able to refuse participation on a per object basis. 
>Three scenarios illustrate the issue of any node refusal:
>
>1)    Web server says no: A cache (or optimizing proxy) improves end 
>user response times and network utilization. A user will often elect to 
>trust this proxy, allowing it to view HTTP2S traffic in the clear, in 
>order to receive the benefit of the optimization. Many content owners 
>will also allow this, especially when serving publicly accessible 
>content. However, some content owners (financial institutions, for 
>instance) may not ever want to allow a proxy to view traffic in the 
>clear, even if the end user allowed it.
>
>examined. In this case, a proxy wants to be able to inform the web 
>server that it will not pass traffic on to the end user that it cannot 
>see.
>
>3)    User/Admin says no: Of course, the obvious scenario is where the 
>user says no. In this case, we have no trusted proxy.
>
>proxy must not be able to run in stealth mode. In order for #2 to be 
>true, the proxy server must be able to pass an indicator to the web 
>server that it requires the ability to see all traffic.
>
>
>
>Solution:
>
>The ideas in James’ Internet Draft Intra-connection Negotiation create 
>consists of a) requiring trusted proxies to have their own 
>point-to-point HTTP2S session with the browser when processing traffic 
>from an HTTP2S content server and b) establishing an intra-connection, 
>end-to-end, TLS session using a NULL cipher (no encrypting but still 
>authenticating and data integrity checking) between browser and web 
>server and using it to send traffic through a trusted proxy. In this 
>case, the traffic over the air is encrypted by the point-to-point TLS 
>sessions, while still being viewable by the proxy, and, at the same 
>time, the browser and web server can authenticate and validate the 
>integrity of the data and any node can refuse participation.
>
>
>
>    Browser                                        Proxy                 
>                       Server
>       | 1)Establish HTTP2S (HTTP2 over TLS) session |                   
>                          |
>
>       | 2)CLIENT_HELLO over HTTP2S                  |                   
>                          |
>
>5)SERVER_HELLO over HTTP2S            |
>
>       |                                             
>       | 6)Forward SERVER_HELLO over HTTP2S          |                   
>                          |
>
>       | 7)Complete TLS negotiation, specifying a NULL cipher, across 
>two HTTP2S sessions         |
>
>       
>       | 8)Unencrypted HTTP2 traffic includes MACs for auth and 
>integrity validation              |
>
>       
>SERVER_HELLO in step 6, it will be able to authenticate the server the 
>same as it would if the trusted proxy were not present. This removes 
>the problem of transitive trust caused by MITM proxies. One can imagine 
>the browser displaying a double lock to indicate that both the proxy 
>and the content server have certificates that have been authenticated – 
>of course the proxy needs an additional layer of validation but again 
>we will not go into that here. The important point is that the proxy is 
>not able to view the traffic unless the browser trusts it and also 
>unless the browser itself has authenticated the web server’s cert with 
>its own database of CAs.
>
>
>
>Message integrity and authentication between browser and web server 
>prevent the proxy from operating in stealth mode, where its presence is 
>undetectable by the web server. The web server can thus refuse to take 
>part in the trusted proxy session on a per object basis. For instance, 
>requests for the logo of a financial institution might be allowed to be 
>viewed by a proxy, but requests for sensitive financial information 
>might be refused. This is what really separates the proposal from 
>simply standardizing MITM because it means the web server will always 
>be aware of the presence of the proxy and because, if it decides to, it 
>can say no. I think this is a powerful feature and one that legitimate 
>middleboxes should also be in favor of, as it allows them to express 
>their intention in an above board way (I would like to optimize this 
>traffic or I must see this traffic in order to scan it for malware) and 
>to be distinguished from rogue MITMs.
>
>
>
>Additionally, the browser will always know when an object was 
>manufactured by the proxy and it can decide whether or not it wants to 
>use it. For instance, a proxy might send the browser a cached copy of 
>an object the browser requested. This cached copy will not contain the 
>MAC proving that it was generated by the web server so the browser will 
>need to make the decision whether or not to use this object. Again, in 
>many cases the browser will agree to because it provides a benefit to 
>the end user.
>
>
>
>flag the TLS data frames it uploads to the web server to indicate 
>whether or not it will allow encrypted responses. If not, as might be 
>the case for a security, malware-detecting appliance, then the web 
>server can decide whether or not it wants to send the data in a way 
>that the proxy can see. And, if not, then the user can be messaged that 
>the site is not viewable with appropriate messaging.
>

---

From: James M Snell <[email-masked]>
Date: Tue, 26 Nov 2013 17:17:08 -0800

Well, a full TLS flow inside the http/2 connection may not be
necessary, but there would have to be some kind of key agreement to
base the message integrity on.. so we'd definitely have to eat up a
round trip or two if we went with this approach... unless the
agreement was negotiated out-of-band (i.e. derived from the external
TLS or some prior agreement). That gets a bit messy, however.

On Tue, Nov 26, 2013 at 3:40 PM, Adrien de Croy <[email-masked]> wrote:
>
> 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
>
> I can see situations where pressure comes to bear on middleware vendors to
> MITM the second layer so that they can alter content.  So I think we need to
> think long and hard before deciding to prohibit that at this stage.
>
> I agree the justification for doing this would be greatly reduced compared
> to the current justification for MITM.
>
> Maybe there's another way to get message integrity without incurring another
> TLS 3 way.
>
> Adrien
>
>
>
> intermediary of HTTP2S traffic (HTTP2 over TLS). One problem in developing a
> standard for an explicit, trusted proxy is the process by which a proxy
> establishes trust. We don't try to tackle that problem here but believe that
> it should be no easier than the current process by which MITM proxies
> establish trust, which is to install a CA certificate into the browser's
> certificate database. So, for instance, one possibility is that the browser
> will have a "trusted proxy partition" in its certificate database and a
> proxy will only be trusted if its certificate is installed there. Again,
> this problem is not solved here.
>
>
>
> The harder problems in designing a standard for explicit trusted proxies are
> 1) the need for message authentication and integrity, meaning the browser
> and server can be confident that the proxy has not tampered with the data
> and 2) any node refusal, by which I mean that all actors (browser, proxy,
> and server) should both express their intentions and be able to refuse
> participation on a per object basis. Three scenarios illustrate the issue of
> any node refusal:
>
> receive the benefit of the optimization. Many content owners will also allow
> this, especially when serving publicly accessible content. However, some
> content owners (financial institutions, for instance) may not ever want to
> allow a proxy to view traffic in the clear, even if the end user allowed it.
>
> the proxy server must be able to pass an indicator to the web server that it
> requires the ability to see all traffic.
>
>
>
> Solution:
>
> The ideas in James’ Internet Draft Intra-connection Negotiation create an
> opportunity for addressing these two problems. The proposed solution
> session using a NULL cipher (no encrypting but still authenticating and data
> integrity checking) between browser and web server and using it to send
> traffic through a trusted proxy. In this case, the traffic over the air is
> encrypted by the point-to-point TLS sessions, while still being viewable by
> the proxy, and, at the same time, the browser and web server can
> authenticate and validate the integrity of the data and any node can refuse
> participation.
>
>
>
> HTTPS stream, so these are over HTTP2, over the point-to-point TLS sessions,
> but they travel end-to-end between browser and server.
>
>
>
> the proxy from operating in stealth mode, where its presence is undetectable
> by the web server. The web server can thus refuse to take part in the
> trusted proxy session on a per object basis. For instance, requests for the
> logo of a financial institution might be allowed to be viewed by a proxy,
> but requests for sensitive financial information might be refused. This is
> what really separates the proposal from simply standardizing MITM because it
> means the web server will always be aware of the presence of the proxy and
> because, if it decides to, it can say no. I think this is a powerful feature
> and one that legitimate middleboxes should also be in favor of, as it allows
> them to express their intention in an above board way (I would like to
> optimize this traffic or I must see this traffic in order to scan it for
> malware) and to be distinguished from rogue MITMs.
>
>
>
> browser requested. This cached copy will not contain the MAC proving that it
> was generated by the web server so the browser will need to make the
> decision whether or not to use this object. Again, in many cases the browser
> will agree to because it provides a benefit to the end user.
>
>
>
> Lastly, and this is not illustrated in the above drawing, the proxy can flag
> the TLS data frames it uploads to the web server to indicate whether or not
> it will allow encrypted responses. If not, as might be the case for a
> security, malware-detecting appliance, then the web server can decide

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 27 Nov 2013 07:20:20 +0100

> TLS or some prior agreement). That gets a bit messy, however.

Wait a minute guys, currently this works *exactly* the same way because
when you use an explicit proxy and want to connect to an https:// URI,
you send a CONNECT method to the proxy to establish a tnunel to the
origin server then you pass your TLS handshake over there. So there is
no difference.

That's exactly what we discussed more than one year ago, offering multiple
possibilities to the user :
  1) connect securely to the proxy, communicate in clear through it and to
     the origin server ;

  2) connect securely to the proxy, communicate in clear through it and have
     the proxy encrypt to the origin server (aka "GET https://").

  3) connect securely to the proxy, and communicate using a TLS tunnel to the
     origin server (equivalent of CONNECT, but with true confidentiality over
     the wire). This is what is described by Peter here.

Most users will prefer #3, and when proxy refuses #3 for the requested site
or whatever, users should be offered the option to switch back to #2 with the
warning about what this implies "this proxy's admin will see everything
exchanged with the site, do you really want to continue ?".

In #3, concerning the extra roundtrip, that's not exact, it's exactly the
same number of round trips as when doing a direct connection to the origin
server. The connection is first established to the proxy and then multiple
streams may be opened there. We can do that in HTTP/1 for http:// URL since
the proxy knows the message length, but not for https:// because of the
CONNECT method which terminates with the connection close. But in both
cases, you save the DNS round trip.

That why I'd really want to see explicit proxies, it will save some round
trips where it matters, especially in mobile environments. And more
importantly we won't see anymore new connections start fresh with a small
congestion window for each object fetched! *That* is critical for performance.

Willy

---

From: Peter Lepeska <[email-masked]>
Date: Wed, 27 Nov 2013 08:37:38 -0500

Comments below.

>      the wire). This is what is described by Peter here.

It is like your #3 except, when no node refuses, the TLS session would use
a NULL cipher. The data in that case is not encrypted but it still contains
a MAC for each message so that browser and web server can authenticate and
check data integrity. You might be right that it's better to build this as
an extension of CONNECT plumbing since that is already the standard
mechanism for establishing an end-to-end TLS session via a proxy. Keep in
mind however that we'd still want to add the proxy messaging to the web
server indicating whether or not it REQUIRED data be sent plaintext TLS,
meaning unencrypted but with auth and data integrity.

> exchanged with the site, do you really want to continue ?".

Can you explain this fall back from #3 to #2 in a little more detail? Why
would the proxy refuse #3? Are you talking about the scenario where the
proxy REQUIRES data be sent in plaintext TLS but the web server refuses?

---

From: Peter Lepeska <[email-masked]>
Date: Wed, 27 Nov 2013 08:48:50 -0500

"Maybe there's another way to get message integrity without incurring
another TLS 3 way."

I don't know of one but I could imagine optimizations that might reduce the
round trips at the expense of keeping TLS and HTTP2 layers separate. I
think it's important to realize Willy's point that this is no different
from the tunnelled TLS that CONNECT enables today. And in fact building
this as an extension of CONNECT might make more sense than using new HTTP2
semantics to achieve pretty much the same thing.

"I agree the justification for doing this would be greatly reduced compared
to the current justification for MITM."

That's the really big point, I think. By reducing the proxy's power to just
what it needs to get its job done, we have a proposal that might be
acceptable to those who currently see the existing "trusted proxy"
proposals as merely standards-based MITM.

Peter

On Tue, Nov 26, 2013 at 6:40 PM, Adrien de Croy <[email-masked]> wrote:

> 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
>
> MITM the second layer so that they can alter content.  So I think we need
> to think long and hard before deciding to prohibit that at this stage.
>
> The ideas in James’ Internet Draft Intra-connection Negotiation<http://www.ietf.org/internet-drafts/draft-snell-httpbis-keynego-01.txt> create
> viewed by a proxy, but requests for sensitive financial information might
> be refused. This is what really separates the proposal from simply
> standardizing MITM because it means the web server will always be aware of
> the presence of the proxy and because, if it decides to, it can say no. I
> think this is a powerful feature and one that legitimate middleboxes should
> also be in favor of, as it allows them to express their intention in an
> above board way (I would like to optimize this traffic or I must see this
> traffic in order to scan it for malware) and to be distinguished from rogue
> MITMs.
>
>
>

---

From: James M Snell <[email-masked]>
Date: Wed, 27 Nov 2013 08:34:48 -0800

On Wed, Nov 27, 2013 at 5:48 AM, Peter Lepeska <[email-masked]> wrote:
> round trips at the expense of keeping TLS and HTTP2 layers separate. I think
> it's important to realize Willy's point that this is no different from the
> tunnelled TLS that CONNECT enables today. And in fact building this as an
> extension of CONNECT might make more sense than using new HTTP2 semantics to
> achieve pretty much the same thing.
>

Indeed. The idea behind the NEGOTIATE mechanism I describe in my draft
is intended to provide for some additional possibilities, but it's not
anywhere near clear yet whether those possibilities are (a)
interesting, (b) practical or (c) realistically feasible. There's
still a ton of work to be done on it.

Today, it ought to be possible to use CONNECT only to enable the most
basic (and likely currently most common) case... however doing so
means performing a complete TLS handshake over a stream. NEGOTIATE
intent at this point is to give us a means of experimenting with
alternatives so that maybe (hopefully) we could come up with a more
efficient approach. Whether or not we'll find it, I'm not yet sure.

> acceptable to those who currently see the existing "trusted proxy" proposals
> as merely standards-based MITM.
>

Exactly. The Intra-Connection approach ought to provide us a way of
bringing trusted intermediaries into the flow legitimately, without
standardizing an attack on TLS. Will there still be NSA's out there?
Sure, absolutely. Can we be sure that we can trust all intermediaries
that use the Intra-Connection approach? Of course not.

- James

>> browser and server can be confident that the proxy has not tampered with the
>> data and 2) any node refusal, by which I mean that all actors (browser,
>> proxy, but requests for sensitive financial information might be refused.
>> This is what really separates the proposal from simply standardizing MITM
>> powerful feature and one that legitimate middleboxes should also be in favor
>> of, as it allows them to express their intention in an above board way (I
>> would like to optimize this traffic or I must see this traffic in order to
>> scan it for malware) and to be distinguished from rogue MITMs.
>>
>>
>>
>> flag the TLS data frames it uploads to the web server to indicate whether or
>> not it will allow encrypted responses. If not, as might be the case for a

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 27 Nov 2013 18:07:28 +0100

> proxy REQUIRES data be sent in plaintext TLS but the web server refuses?

Yes that's exactly that. Let's simply imagine what any proxy admin needs to
do :
  - inspect contents exchanged with webmails and social networks
  - offer the guarantee to their users that a few sites are whitelisted
    and will not be deciphered

So the admin will configure the proxy this way :
  - allow CONNECT paypal.com mybank.com yourbank.com theirbank.com
  - reject CONNECT
  - allow GET over https

At the moment with HTTP/1.1 this is not possible so the two policies are
merged into a single choice that depends on the place where the proxy is
deployed :
  - either allow CONNECT for a few sites and reject all other https sites.
  - or decrypt everything even what shouldn't. Anyway the user hardly knows.

Regards,
Willy

---

From: Peter Lepeska <[email-masked]>
Date: Wed, 27 Nov 2013 14:13:51 -0500

You lost me. I think because you are blending other ideas, which is great
by me but I just want to clarify.

In my proposal, there are three types of messages (requests and responses):
1) End-to-end encrypted that the proxy cannot see
2) End-to-end not encrypted but with message auth and integrety (encrypted
over the air by point-to-point TLS sessions)
3) Messages generated by the proxy that does not contain MACs that the
browser can use if it wishes.

Both #1 and #2 could potentially use the "CONNECT" verb instead of using
Intra-Connection Negotiation as I proposed. For #2, the browser and server
simply negotiate the use of a NULL cipher.

I don't see how your "allow GET over https" fits into this scheme.

Can you explain?

Peter

On Wed, Nov 27, 2013 at 12:07 PM, Willy Tarreau <[email-masked]> wrote:

> > >   3) connect securely to the proxy, and communicate using a TLS tunnel
> to
> > > the
> > >      origin server (equivalent of CONNECT, but with true
> confidentiality
> > > over
> > > or whatever, users should be offered the option to switch back to #2
> with
> > > the

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 27 Nov 2013 21:53:08 +0100

> 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

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 27 Nov 2013 20:58:54 +0000

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" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Peter Lepeska" <[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 28/11/2013 9:53:08 a.m.
Subject: Re: Proposal: Explicit HTTP2S proxy with any node refusal
>>endure