Re: new draft trusted-proxy20-00
"Adrien de Croy" <adrien@qbik.com> Wed, 15 January 2014 21:36 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 622911AE414 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 15 Jan 2014 13:36:36 -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 SAdajy2i7unO for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 15 Jan 2014 13:36:30 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4EE1AE237 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 15 Jan 2014 13:36:30 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1W3Y7K-00019j-Nq for ietf-http-wg-dist@listhub.w3.org; Wed, 15 Jan 2014 21:35:18 +0000
Resent-Date: Wed, 15 Jan 2014 21:35:18 +0000
Resent-Message-Id: <E1W3Y7K-00019j-Nq@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 1W3Y7D-00015E-E6 for ietf-http-wg@listhub.w3.org; Wed, 15 Jan 2014 21:35:11 +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 1W3Y7B-0006Se-5q for ietf-http-wg@w3.org; Wed, 15 Jan 2014 21:35:11 +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 <0019936371@smtp.qbik.com>; Thu, 16 Jan 2014 10:34:39 +1300
From: Adrien de Croy <adrien@qbik.com>
To: Peter Lepeska <bizzbyster@gmail.com>, 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>
Date: Wed, 15 Jan 2014 21:34:39 +0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; format="flowed"; charset="utf-8"
In-Reply-To: <CANmPAYGqMMOQgMw2V3A66txr7Yu=won9NHSxu-LYxhcTp+f2Dw@mail.gmail.com>
Message-Id: <eme32fa5b9-bfa9-45e5-a17f-65c266de05af@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.274, RP_MATCHES_RCVD=-0.325, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1W3Y7B-0006Se-5q f9b78cfb3acaa6800b7da0bfaf881132
X-Original-To: ietf-http-wg@w3.org
Subject: Re: new draft trusted-proxy20-00
Archived-At: <http://www.w3.org/mid/eme32fa5b9-bfa9-45e5-a17f-65c266de05af@bodybag>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/21812
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>
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