Subject: Explicit Proxy (draft-rpeon-httpbis-exproxy)

From: Chad Goss <[email-masked]>
Date: Fri, 13 Jul 2012 12:01:16 -0400

Hi,
I have read the draft, the primary question I had was what is the mechanism
to transfer the decryption key material from user-agent to configured-proxy
in a secure, authenticated and trusted manner immediately after tunnel
establishment, and how are you going to do that prior to any traffic
traversing the tunnel?

thanks
-chad

---

From: Roberto Peon <[email-masked]>
Date: Fri, 13 Jul 2012 09:47:16 -0700

On Jul 13, 2012 9:03 AM, "Chad Goss" <[email-masked]> wrote:
>
> Hi,
> I have read the draft, the primary question I had was what is the
mechanism to transfer the decryption key material from user-agent to
configured-proxy in a secure, authenticated and trusted manner immediately
after tunnel establishment, and how are you going to do that prior to any
traffic traversing the tunnel?

The draft is light on those details, to say the least. We'd have to define
a field (of a headers frame ) or frame that transported that information.
Since the client is configured to do this, it knows to emit that frame as
soon as the TLS tunnel has been established.

-=R

On Jul 13, 2012 9:03 AM, "Chad Goss" <[email-masked]> wrote:

> Hi,
> I have read the draft, the primary question I had was what is the
> mechanism to transfer the decryption key material from user-agent to
> configured-proxy in a secure, authenticated and trusted manner immediately
> after tunnel establishment, and how are you going to do that prior to any
> traffic traversing the tunnel?
>
> thanks
> -chad
>
>

---

From: Chad Goss <[email-masked]>
Date: Wed, 18 Jul 2012 20:33:46 -0400

>
> Hi All,
>>
>> Understand from Roberto the proposal requires that a secure tunnel has
>> already been established from the user-agent to the proxy. So the sequence
>> would be something along the lines of:
>>
>>
>>
>> 0. authentication credentials are installed on user-agent and
>> configured-proxy such that an HTTPS connection can be created successfully.
>>
>>
>>
>> 1. browser launches
>>
>>   1a. If the configured proxy is a trusted proxy, connect to it and
>> establishes a trusted pipe which remains up, and over which other HTTPS
>> established session keys will be transmitted.
>>
>>   1b. If the configured proxy is a caching proxy, do not establish tunnel
>> to it.
>>
>>
>>
>> 2. user-agent requests a page
>>
>>   2a. If the initial request was for HTTP, automatically route it over
>> HTTPS
>>
>>   2b. If the initial request was for HTTPS, proceed as normal
>>
>>
>>
>> 3. browser establishes an HTTPS connection to the content server, creates
>> ephemeral session key
>>
>> 4. If the configured proxy is a trusted proxy, browser sends the session
>> key to it, gets acknowledgement that it was received
>>
>> 5. browswer starts requesting data from content server over HTTPS.
>>
>> 6. trusted proxy decrypts data, inspects, forwards if that decision is
>> allowed for that packet.
>>
>>
>>
>> Questions, apologize if they have been asked/answered before:
>>
>> A. Is that sequence accurate?
>>
>> B. What assurances would be given to the users of this scheme that their
>> ephemeral session keys would be securely managed during an active session,
>> and destroyed immediately following?
>>
>> C.  How are we getting buy in from the content-server to authorize the
>> session to be decrypted?
>>
>> D. Would it be possible to create two categories of trusted proxy HTTPS
>> sessions? One that was allowed to be decrypted, one that wasn’t? The reason
>> I suggest this, is that I would be fine running all of my current HTTP
>> traffic over a scheme such as this, but I would never want my current HTTPS
>> (like banking) to run over a trusted proxy. This scheme doesn’t seem to
>> allow me that ability (since the configured proxy is designated as either
>> trusted or caching initially)? That might be the “mixed trust mode”? If so,
>> it would seem like having the ability to signal that situation was
>> necessary for the document? It would also be nice to have the ability to
>> separately configure security on the proxies.
>>
>> E. Does it seem like a leap to predicate so much of this proposal on
>> having all content-servers running HTTPS, and serving all content up over
>> that?
>>
>> F. In general, it would seem necessary to be able to distinguish between
>> #2a and #2b when determining the security associated with the tunnel
>> established in #3. In the #2a case, I would certainly be willing to live
>> with minimal security to improve performance..
>>
>>
>>
>> Thanks for your time
>>
>> -chad
>>
>>
>>
>>
>>
>> =================================
>>
>>
>>
>> D.  Would
>>
>>
>>
>> On Fri, Jul 13, 2012 at 12:47 PM, Roberto Peon <[email-masked]> wrote:
>>
>>
>> The draft is light on those details, to say the least. We'd have to
>> define a field (of a headers frame ) or frame that transported that
>> information.