Re: new draft trusted-proxy20-00
"Adrien de Croy" <adrien@qbik.com> Wed, 15 January 2014 22:54 UTC
Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941A31AE2B6 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 15 Jan 2014 14:54:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.44
X-Spam-Level:
X-Spam-Status: No, score=-7.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8P41EXDyvKu for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 15 Jan 2014 14:54:41 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9761A1AE2AC for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 15 Jan 2014 14:54:41 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1W3ZKs-0002Ma-Rj for ietf-http-wg-dist@listhub.w3.org; Wed, 15 Jan 2014 22:53:22 +0000
Resent-Date: Wed, 15 Jan 2014 22:53:22 +0000
Resent-Message-Id: <E1W3ZKs-0002Ma-Rj@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <adrien@qbik.com>) id 1W3ZKm-0002Lm-P0 for ietf-http-wg@listhub.w3.org; Wed, 15 Jan 2014 22:53:16 +0000
Received: from smtp.qbik.com ([210.55.214.35]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <adrien@qbik.com>) id 1W3ZKl-0000Dk-5O for ietf-http-wg@w3.org; Wed, 15 Jan 2014 22:53:16 +0000
Received: From [192.168.0.38] (unverified [192.168.0.38]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v8.1.0 (Build 4648)) with SMTP id <0019936438@smtp.qbik.com>; Thu, 16 Jan 2014 11:52:47 +1300
From: Adrien de Croy <adrien@qbik.com>
To: Peter Lepeska <bizzbyster@gmail.com>
Cc: Yoav Nir <synp71@live.com>, Salvatore Loreto <salvatore.loreto@ericsson.com>, HTTP Working Group <ietf-http-wg@w3.org>, Robert Skog <robert.skog@ericsson.com>, Hans Spaak <hans.spaak@ericsson.com>, John Mattsson <john.mattsson@ericsson.com>
Date: Wed, 15 Jan 2014 22:52:47 +0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; format="flowed"; charset="utf-8"
In-Reply-To: <CANmPAYGTdngRpFcjXr-m0v9cJfU9ZNdHn2u6CXY-oGfy5dP_pw@mail.gmail.com>
Message-Id: <em59fda96b-c2bf-4593-b431-1fc36803c87f@bodybag>
Mime-Version: 1.0
Reply-To: Adrien de Croy <adrien@qbik.com>
User-Agent: eM_Client/6.0.19714.0
Received-SPF: pass client-ip=210.55.214.35; envelope-from=adrien@qbik.com; helo=smtp.qbik.com
X-W3C-Hub-Spam-Status: No, score=-3.6
X-W3C-Hub-Spam-Report: AWL=-3.234, RP_MATCHES_RCVD=-0.325, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1W3ZKl-0000Dk-5O a854d6ae0db602685059d647ae92bf48
X-Original-To: ietf-http-wg@w3.org
Subject: Re: new draft trusted-proxy20-00
Archived-At: <http://www.w3.org/mid/em59fda96b-c2bf-4593-b431-1fc36803c87f@bodybag>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/21818
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Actually there's maybe another option that wouldn't require changing TLS or HTTP. it would need to go down a layer to TCP though. In intercepting proxies, the first thing is the TCP 3 way handshake. If this could be extended (TCP option) then we could achieve the same result, but use it for any TCP-based protocol not just http and TLS. I'm sure this idea will go down like a lead balloon, but there are less useful TCP options that have been standardised (and largely ignored) I'm pretty sure. ------ Original Message ------ From: "Peter Lepeska" <bizzbyster@gmail.com> To: "Adrien de Croy" <adrien@qbik.com> Cc: "Yoav Nir" <synp71@live.com>; "Salvatore Loreto" <salvatore.loreto@ericsson.com>; "HTTP Working Group" <ietf-http-wg@w3.org>; "Robert Skog" <robert.skog@ericsson.com>; "Hans Spaak" <hans.spaak@ericsson.com>; "John Mattsson" <john.mattsson@ericsson.com> Sent: 16/01/2014 11:47:49 Subject: Re: new draft trusted-proxy20-00 >Okay. In your case #2, maybe the second ClientHello will need a flag >that says "I know you are there proxy but I don't want use you" so >that distinguishing between the first and second type of ClientHello >is straightforward. > >Peter > >On Wed, Jan 15, 2014 at 4:34 PM, Adrien de Croy <adrien@qbik.com> >wrote: >> >> What I would expect in this mechanism, is that you wouldn't get the >>Client >> Hello blocked unless the proxy was asserting that it must be used. >> >> Otherwise you'd need 2 different types of response - 1 "you must use >>me", or >> 2 "you can try again and I won't block it next time honest" >> >> In case 1, the user gets to choose between >> >> 1. I will trust the proxy; or >> 2. I will not use the internet >> >> which is a perfectly reasonable choice IMO. Just like the EULA page >>on many >> a software installer. >> >> Cheers >> >> Adrien >> >> >> ------ Original Message ------ >> From: "Peter Lepeska" <bizzbyster@gmail.com> >> To: "Yoav Nir" <synp71@live.com> >> Cc: "Salvatore Loreto" <salvatore.loreto@ericsson.com>; "HTTP Working >>Group" >> <ietf-http-wg@w3.org>; "Robert Skog" <robert.skog@ericsson.com>; >>"Hans >> Spaak" <hans.spaak@ericsson.com>; "John Mattsson" >> <john.mattsson@ericsson.com> >> Sent: 16/01/2014 07:31:03 >> Subject: Re: new draft trusted-proxy20-00 >> >>> More questions: >>> >>> "The proxy intercept and does not forward the ClientHello message, >>> instead it returns a signed error message ("Here be proxies") >>> containing a certificate identifying the proxy. " >>> >>> What happens if the client decides that it does not trust the proxy? >>> Does it send a new ClientHello that the proxy forwards? How does the >>> proxy distinguish between the first ClientHello that it does not >>> forward and the second ClientHello that it does forward? >>> >>> Or, on the other hand, is trusting the proxy required to use the >>> network in the use case for this new mechanism? >>> >>> Thanks, >>> >>> Peter >>> >>> >>> >>> But taking a step back, it seems like you are proposing a way for a >>> proxy to advertise its presence for HTTPS connections. D >>> >>> On Mon, Jan 13, 2014 at 9:55 AM, Yoav Nir <synp71@live.com> wrote: >>>> >>>> Hi, Salvatore >>>> >>>> Thanks for writing this. A few comments: >>>> >>>> Section 3.1 has the HTTP proxy indicate its presence by >>>>intercepting the >>>> ClientHello and returning an error. There are some issue here: >>>> >>>> * An explicit proxy does not have to be on the data path, and in >>>>fact >>>> it usually isn't. While MitM proxies have to intercept, clients >>>>open >>>> connections to explicit proxies, so they're likely to reside in >>>>a >>>> data-center (sometimes even in the cloud). Blocking HTTP(S) >>>>falls to >>>> a network firewall. In other words, a MitM proxy usually needs >>>>to be >>>> co-located with the firewall, but not so for an explicit proxy. >>>> * I don't get how the firewall is supposed to redirect the client >>>>to >>>> the proxy. The third paragraph says "The error could for e.g. >>>>be >>>> sent using the TLS Alert protocol, but this requires >>>>registration of >>>> a new error type." I didn't understand whether this is what you >>>>are >>>> recommending (at least for this solution) or whether there are >>>>other >>>> options. It should be noted that in order for the firewall to >>>>be >>>> able to send TLS alerts, it has to MitM at least TCP, as the >>>>browser >>>> thinks it is opening a connection with the server. If we were >>>> specifying the Internet from scratch, we could define an ICMP >>>> message that can be sent to the browser in response to the >>>>TCP-SYN >>>> packet. I'm not sure how well that would work, and whether the >>>> operating systems that we're using even have APIs to tell the >>>> application what the content of the ICMP was, so I guess we're >>>>stuck >>>> with firewalls impersonating servers at the TCP layer. >>>> >>>> Section 4.1 describes tunneling by using the HTTP CONNECT method, >>>>but >>>> then >>>> the connection between the UA and the proxy is described at an >>>>HTTPS2 >>>> connection, and the proxy seems to have access to the request >>>>frames. >>>> Specifically, a decryption key is passed in an HTTP2 frame. To add >>>>to >>>> the >>>> confusion, the title of this section is "Tunneling". The CONNECT >>>>method >>>> does >>>> go with the term "Tunneling", but then the TLS session is between >>>>the UA >>>> and >>>> the server, while the proxy only sees TLS records and cannot read >>>>any of >>>> the >>>> HTTP2 frames, which may share a TLS record, or span several TLS >>>>records. >>>> With tunneling, the proxy does little more than moving packets >>>>back and >>>> forth. >>>> >>>> The alternative to tunneling, that is sort-of described in section >>>>4.2 >>>> is >>>> the use of a GET method. In this case the client really opens an >>>> HTTPS(2) >>>> connection to the proxy, and then sends a GET method for resource >>>> "https://server.example.com/resource.html". The server has a >>>>totally >>>> separate TLS connection with the server and tunnels the requests >>>>back >>>> and >>>> forth. If the proxy can reply to a request from its own cache, it >>>>may do >>>> so. >>>> If it is configured to inspect the content to filter out >>>>inappropriate >>>> content, it can do that as well. *This* is a trusted proxy. A >>>>proxy with >>>> tunneling does not need to be trusted any more than the Internet >>>>does. >>>> >>>> Lastly, section 4.2 says that the UA "tunnels" all requests >>>>towards the >>>> same >>>> web server in a single connection. In fact, the UA can tunnel all >>>>of its >>>> requests towards all servers in the world through this connection. >>>> Similarly, the proxy could unify the traffic for several UAs into >>>>a >>>> single >>>> connection with the server. This would work for normal servers, >>>>but do >>>> we >>>> know that no servers make any assumptions about requests based on >>>>TCP >>>> connection? I know they shouldn't - that's what HTTP cookies are >>>>for - >>>> but >>>> it's possible that some do. >>>> >>>> Yoav >>>> >>>> >>>> >>>> On 10/1/14 1:51 PM, Salvatore Loreto wrote: >>>>> >>>>> >>>>> Hi there, >>>>> >>>>> we have submitted a new draft with the aim to continue the >>>>>discussion >>>>> on >>>>> explicit and trusted proxy as intermediary of HTTP2S traffic: >>>>> >>>>> >>>>> >>>>>http://www.ietf.org/internet-drafts/draft-loreto-httpbis-trusted-proxy20-00.txt >>>>> >>>>> >>>>> The document proposes a method for an user agent to automatically >>>>> discover (using the TLS Alert) and configure a proxy via a secure >>>>> HTTP2.0 >>>>> session. >>>>> >>>>> Moreover the document also draft two alternative mechanisms that >>>>>allow >>>>> the presence of HTTP2.0 secure proxies for TLS protected traffic >>>>>when >>>>> an >>>>> user-agent >>>>> is requesting an http resource. >>>>> >>>>> br >>>>> Salvatore >>>> >>>> >>>> >>>> >>> >>
- new draft trusted-proxy20-00 Salvatore Loreto
- Re: new draft trusted-proxy20-00 Yoav Nir
- Re: new draft trusted-proxy20-00 Nicolas Mailhot
- Re: new draft trusted-proxy20-00 Adrien de Croy
- Re: new draft trusted-proxy20-00 Nicolas Mailhot
- Re: new draft trusted-proxy20-00 Peter Lepeska
- Re: new draft trusted-proxy20-00 Peter Lepeska
- Re: new draft trusted-proxy20-00 Adrien de Croy
- Re: new draft trusted-proxy20-00 Peter Lepeska
- Re: new draft trusted-proxy20-00 Adrien de Croy
- Re: new draft trusted-proxy20-00 Salvatore Loreto
- Re: new draft trusted-proxy20-00 Salvatore Loreto
- Re: new draft trusted-proxy20-00 Salvatore Loreto