Re: Portal authorization
Amos Jeffries <squid3@treenet.co.nz> Fri, 13 April 2012 04:26 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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7000121F8771 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 12 Apr 2012 21:26:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.224
X-Spam-Level:
X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_RMML_Stock10=0.13]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-8FaFd3ubym for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 12 Apr 2012 21:26:05 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3F00021F86B0 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 12 Apr 2012 21:26:05 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1SIY48-0001Hx-Bl for ietf-http-wg-dist@listhub.w3.org; Fri, 13 Apr 2012 04:24:56 +0000
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <squid3@treenet.co.nz>) id 1SIY3q-00019R-82 for ietf-http-wg@listhub.w3.org; Fri, 13 Apr 2012 04:24:38 +0000
Received: from ip-58-28-153-233.static-xdsl.xnet.co.nz ([58.28.153.233] helo=treenet.co.nz) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1SIY3m-0001zZ-C1 for ietf-http-wg@w3.org; Fri, 13 Apr 2012 04:24:36 +0000
Received: from [10.1.1.14] (unknown [119.224.40.49]) by treenet.co.nz (Postfix) with ESMTP id 001BEE6D7E for <ietf-http-wg@w3.org>; Fri, 13 Apr 2012 16:24:10 +1200 (NZST)
Message-ID: <4F87AA68.9020808@treenet.co.nz>
Date: Fri, 13 Apr 2012 16:24:08 +1200
From: Amos Jeffries <squid3@treenet.co.nz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: ietf-http-wg@w3.org
References: <4F763DD2.70604@isode.com> <em3e102790-aa55-4d0f-9ff3-39bf0ca77fd3@boist> <CABaLYCvGt=pqwVXaWMMUTyD1Gg=qizRG_WuekC33awBRu53AAQ@mail.gmail.com> <4F76AABF.3010201@gmx.de> <CABaLYCsB+outivXFwj8iFH+dM6XedxwR672Rw7pOhtzj7r6X-A@mail.gmail.com> <loom.20120406T155512-618@post.gmane.org> <CAA4WUYipNcFpigX4MHQHOtM-M0vFBSRjMJLZnpN6GXkPinVNMw@mail.gmail.com> <50b278cb647638c66ee1db0fe1bf8488.squirrel@arekh.dyndns.org> <20120407192933.GA3240@jl-vm1.vm.bytemark.co.uk> <502fe0631a8a28bce027c70c6e733c38.squirrel@arekh.dyndns.org> <20120409151210.GC3240@jl-vm1.vm.bytemark.co.uk> <4F838D59.50304@it.aoyama.ac.jp> <11509b6f410771fb81c08b9d7cfc2e12.squirrel@arekh.dyndns.org> <4F840795.9090505@gmx.de> <6fe22d5f627ff564d9c2dc43e6e55a00.squirrel@arekh.dyndns.org>
In-Reply-To: <6fe22d5f627ff564d9c2dc43e6e55a00.squirrel@arekh.dyndns.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=58.28.153.233; envelope-from=squid3@treenet.co.nz; helo=treenet.co.nz
X-W3C-Hub-Spam-Status: No, score=-1.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1SIY3m-0001zZ-C1 07520ddaba0e73ef10ca9f30de15806e
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Portal authorization
Archived-At: <http://www.w3.org/mid/4F87AA68.9020808@treenet.co.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/13432
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>
Resent-Message-Id: <E1SIY48-0001Hx-Bl@frink.w3.org>
Resent-Date: Fri, 13 Apr 2012 04:24:56 +0000
On 10/04/2012 11:03 p.m., Nicolas Mailhot wrote: > Le Mar 10 avril 2012 12:12, Julian Reschke a écrit : >> On 2012-04-10 09:00, Nicolas Mailhot wrote: >>> Le Mar 10 avril 2012 03:31, "Martin J. Dürst" a écrit : >>>> Hello Jamie, others, >>>> >>>> Mark had a draft on this, >>>> http://tools.ietf.org/html/draft-nottingham-http-portal-02. I'm not sure >>>> why it didn't move forward. >>> I think it morphed in http error 511 however: >>> >>> 1. error 511 does not return an url so it can't be handled by dumb web >>> clients >>> such as curl >> Nor did the proposal in draft-nottingham-http-portal-02. Also, handling >> by dumb web clients was never on the agenda for this code, and I'm also >> not sure how it's supposed to work. > As started on the curl or git list dumb clients can not render a complex auth > page. They could give the user the address of this page, so he could open it > in a smarter client, if they had this address available in the HTTP 511 > headers. > > http://lists-archives.com/git/763532-handle-http-error-511-network-authentication-required-standard-secure-proxy-authentification-captive-portal-detection.html > >>> 2. browser people do not like it. Gateway auth really needs to be specified >>> once and for all in a document with browser buy-in such as http/2 >> Please do not make blanket statements like these unless you can back >> them up. > Right now http/1 is perceived as an end-to-end protocol with no provision for > intermediaries. And the situation is worse with TLS. If http/2 adds > multiplexing, this multiplexing should make it explicit intermediaries exist > and make a channel available for intermediaries to add their signalling That perception is plain wrong. HTTP/1 has always had the definition of a proxy built-in as much as SMTP has the concept of a relay built-in. The *T* in TLS does not alter the hop-by-hop nature. That is an illusion. Even CONNECT can and does traverse multiple hops from the tunnel endpoint to the origin destination. > Right now what browser people have written about error 511 > > | Doing something "useful" with 511-over-MITMed-SSL would mean a huge increase > | in attack surface: > | * We'd have to poke a hole all the way through our TLS stack to even see the > | 511. > > | A new HTTP status code won't help this bug because we get the SSL certificate > | name mismatch error before we can send an HTTP request. > > (the "end-to-end" only argument) The reality more often than not being: A =>B=>C->D A makes CONNECT through B to "endpoint" C. C relays to D. D responds through C to A. When B requires authentication ... only Basic and Kerberos seem to work nicely. When B requires all inbound requests be made over TLS connections ... only Chrome seems to work easily. > > | 3. We determine, from that error, whether we think we should try to detect > | the captive portal. If so, we issue a request to captive-portal > | test-mozilla.org. If that response comes back as a 511, or with a wispr > | response, or some other indication that we're in a captive portal, then we > | kick into captive portal mode. > > (the "let's ignore proxy signalling and try to guess location by our own" > argument) Your brief summary says it all really. If they dont trust the endpoint they are connected to at least signal its own needs and location properly, what hope is left? The person using this argument would be terrified by ARP spoofing. > > | But, I don't think we should avoid implementing a solution for the most > | common cases just because there are a few (or even many) cases where it > | wouldn't work. > > ("it's hard, let us do it some other day" argument) > > It's a hard problem which had no satisfactory answer so far and which > resolution has been postponed for all of http/1 life. Please do not make the > same mistake with http/2 and provide for intermediaries from the start up. We are required to maintain semantic compatibility with HTTP/1. Proxy-auth headers remain in all proposals. Pity the browser who dont implement them for captive portals. The argument from the captive portal people is simply to get browsers to pay attention to portal / proxy signals and act as if the portal existed. Stop complicating things by pretending end-to-end for everything (including TLS port 443) even when the protocol signals are clear and loud that a proxy exists in the middle. When the nay-sayers can get over that paradigm shift even HTTP/1 will be able to work better. > > https://code.google.com/p/chromium/issues/detail?id=71736 > https://bugzilla.mozilla.org/show_bug.cgi?id=728658 > > Best regards, > AYJ
- Re: multiplexing -- don't do it Adrien W. de Croy
- multiplexing -- don't do it Peter L
- Re: multiplexing -- don't do it Brian Pane
- Re: multiplexing -- don't do it J Ross Nicoll
- Re: multiplexing -- don't do it Mike Belshe
- RE: multiplexing -- don't do it Peter L
- RE: multiplexing -- don't do it Peter L
- Re: multiplexing -- don't do it Brian Pane
- Re: multiplexing -- don't do it Roberto Peon
- RE: multiplexing -- don't do it Peter L
- RE: multiplexing -- don't do it Peter L
- Re: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Alexey Melnikov
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Julian Reschke
- Re: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Poul-Henning Kamp
- Re: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Ian Fette (イアンフェッティ)
- Re: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Mark Nottingham
- Re: multiplexing -- don't do it Peter L
- Re: multiplexing -- don't do it Peter L
- Re: multiplexing -- don't do it Adam Barth
- Re: multiplexing -- don't do it Roberto Peon
- Re: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Peter Lepeska
- Re[2]: multiplexing -- don't do it Adrien W. de Croy
- Re: Re[2]: multiplexing -- don't do it Peter L
- Re[4]: multiplexing -- don't do it Adrien W. de Croy
- Re: Re[4]: multiplexing -- don't do it William Chan (陈智昌)
- Re: multiplexing -- don't do it Amos Jeffries
- Re: Re[2]: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Amos Jeffries
- Re: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Poul-Henning Kamp
- Re: multiplexing -- don't do it Mark Nottingham
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Peter Lepeska
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Adrien W. de Croy
- breaking TLS (Was: Re: multiplexing -- don't do i… Stephen Farrell
- Re: multiplexing -- don't do it Roberto Peon
- Re: breaking TLS (Was: Re: multiplexing -- don't … Adrien W. de Croy
- Re: breaking TLS (Was: Re: multiplexing -- don't … Roberto Peon
- Re: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Roberto Peon
- Re: multiplexing -- don't do it Ray Polk
- Re: multiplexing -- don't do it Roberto Peon
- Re: multiplexing -- don't do it Mark Nottingham
- Re: breaking TLS (Was: Re: multiplexing -- don't … Stephen Farrell
- Re: multiplexing -- don't do it J Ross Nicoll
- Re: multiplexing -- don't do it Roberto Peon
- Re: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Adrien W. de Croy
- Re: breaking TLS (Was: Re: multiplexing -- don't … Adrien W. de Croy
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: breaking TLS (Was: Re: multiplexing -- don't … Mike Belshe
- Re: multiplexing -- don't do it Robert Collins
- Re: breaking TLS (Was: Re: multiplexing -- don't … Stephen Farrell
- Re[2]: multiplexing -- don't do it Adrien W. de Croy
- Re: breaking TLS (Was: Re: multiplexing -- don't … William Chan (陈智昌)
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re[3]: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it patrick mcmanus
- Re: Re[3]: multiplexing -- don't do it Robert Collins
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: breaking TLS (Was: Re: multiplexing -- don't … Stephen Farrell
- Re: multiplexing -- don't do it Amos Jeffries
- Re: multiplexing -- don't do it Stephen Farrell
- Re: multiplexing -- don't do it Amos Jeffries
- Re: breaking TLS (Was: Re: multiplexing -- don't … William Chan (陈智昌)
- Re: breaking TLS (Was: Re: multiplexing -- don't … Stephen Farrell
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: multiplexing -- don't do it patrick mcmanus
- Re: breaking TLS (Was: Re: multiplexing -- don't … Amos Jeffries
- Re[2]: breaking TLS (Was: Re: multiplexing -- don… Adrien W. de Croy
- Re: breaking TLS (Was: Re: multiplexing -- don't … Martin Thomson
- Re[2]: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Stephen Farrell
- Re[2]: multiplexing -- don't do it Adrien W. de Croy
- Re: breaking TLS (Was: Re: multiplexing -- don't … Willy Tarreau
- Re: multiplexing -- don't do it Mike Belshe
- proxy config (was Re: multiplexing -- don't do it) Daniel Stenberg
- Re: multiplexing -- don't do it Roberto Peon
- Re: multiplexing -- don't do it J Ross Nicoll
- Re: multiplexing -- don't do it Stephen Farrell
- Re: breaking TLS (Was: Re: multiplexing -- don't … Henry Story
- Re: multiplexing -- don't do it Mike Belshe
- RE: proxy config (was Re: multiplexing -- don't d… Eric Lawrence
- Re: multiplexing -- don't do it Roy T. Fielding
- Re: multiplexing -- don't do it Poul-Henning Kamp
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re[2]: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Poul-Henning Kamp
- Re: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Patrick McManus
- Re: multiplexing -- don't do it Peter Lepeska
- Re: multiplexing -- don't do it Peter Lepeska
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Peter L
- Re: multiplexing -- don't do it Peter L
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: multiplexing -- don't do it Roberto Peon
- Re: multiplexing -- don't do it William Chan (陈智昌)
- options or protocols? Eliot Lear
- Re: options or protocols? Adrien W. de Croy
- Re: options or protocols? Willy Tarreau
- Re: options or protocols? Adrien W. de Croy
- Re: options or protocols? Willy Tarreau
- Re: options or protocols? Adrien de Croy
- Re: options or protocols? William Chan (陈智昌)
- Re: options or protocols? Willy Tarreau
- Re: multiplexing -- don't do it Patrick McManus
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: multiplexing -- don't do it Peter Lepeska
- Re: multiplexing -- don't do it Peter Lepeska
- Re: multiplexing -- don't do it Peter Lepeska
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: multiplexing -- don't do it Jon Leighton
- Re: multiplexing -- don't do it Roberto Peon
- Re: multiplexing -- don't do it Peter Lepeska
- Re: breaking TLS (Was: Re: multiplexing -- don't … Nicolas Mailhot
- HTTP -> Messages -> Transport factoring Mark Nottingham
- Re: HTTP -> Messages -> Transport factoring Mike Belshe
- Re: multiplexing -- don't do it Mike Belshe
- RE: HTTP -> Messages -> Transport factoring Henrik Frystyk Nielsen
- Re: HTTP -> Messages -> Transport factoring Mark Nottingham
- Re: multiplexing -- don't do it Jon Leighton
- Re: HTTP -> Messages -> Transport factoring Poul-Henning Kamp
- Re: HTTP -> Messages -> Transport factoring Willy Tarreau
- Re: HTTP -> Messages -> Transport factoring Willy Tarreau
- Re: HTTP -> Messages -> Transport factoring Carsten Bormann
- Re: HTTP -> Messages -> Transport factoring Poul-Henning Kamp
- Re: HTTP -> Messages -> Transport factoring Carsten Bormann
- Re: options or protocols? Adrien de Croy
- Re: HTTP -> Messages -> Transport factoring Mike Belshe
- Re: HTTP -> Messages -> Transport factoring David Morris
- Re: HTTP -> Messages -> Transport factoring Mike Belshe
- Re: multiplexing -- don't do it Nicolas Mailhot
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: breaking TLS (Was: Re: multiplexing -- don't … Nicolas Mailhot
- Re: breaking TLS (Was: Re: multiplexing -- don't … William Chan (陈智昌)
- Re: multiplexing -- don't do it Nicolas Mailhot
- Re: breaking TLS (Was: Re: multiplexing -- don't … Nicolas Mailhot
- Re: breaking TLS (Was: Re: multiplexing -- don't … Mike Belshe
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Nicolas Mailhot
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: breaking TLS (Was: Re: multiplexing -- don't … Stephen Farrell
- Re: multiplexing -- don't do it Stephen Farrell
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: multiplexing -- don't do it Stephen Farrell
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: multiplexing -- don't do it Poul-Henning Kamp
- Re: multiplexing -- don't do it Roberto Peon
- RE: multiplexing -- don't do it Henrik Frystyk Nielsen
- Re: multiplexing -- don't do it Stephen Farrell
- Re: multiplexing -- don't do it Nicolas Mailhot
- Re: multiplexing -- don't do it Willy Tarreau
- Re: breaking TLS (Was: Re: multiplexing -- don't … Willy Tarreau
- Re: breaking TLS (Was: Re: multiplexing -- don't … Roberto Peon
- Re: breaking TLS (Was: Re: multiplexing -- don't … Stephen Farrell
- Re: breaking TLS (Was: Re: multiplexing -- don't … Willy Tarreau
- Re: breaking TLS (Was: Re: multiplexing -- don't … Poul-Henning Kamp
- Re: breaking TLS (Was: Re: multiplexing -- don't … Willy Tarreau
- Re: breaking TLS (Was: Re: multiplexing -- don't … Daniel Stenberg
- Re: breaking TLS (Was: Re: multiplexing -- don't … Poul-Henning Kamp
- Re: breaking TLS (Was: Re: multiplexing -- don't … Roberto Peon
- Re: multiplexing -- don't do it tom
- Re: multiplexing -- don't do it tom
- Re: multiplexing -- don't do it patrick mcmanus
- Re: multiplexing -- don't do it tom
- Re: multiplexing -- don't do it Jamie Lokier
- Re: multiplexing -- don't do it Jamie Lokier
- Re: multiplexing -- don't do it David Morris
- Re: multiplexing -- don't do it Peter Lepeska
- Re: multiplexing -- don't do it Roberto Peon
- Re[2]: multiplexing -- don't do it Adrien W. de Croy
- Re[2]: multiplexing -- don't do it Adrien W. de Croy
- Re: Re[2]: multiplexing -- don't do it Poul-Henning Kamp
- Re[4]: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Nicolas Mailhot
- Re: multiplexing -- don't do it Jamie Lokier
- Portal authorization (was: Re: multiplexing -- do… Martin J. Dürst
- Re: multiplexing -- don't do it Nicolas Mailhot
- Re: Portal authorization (was: Re: multiplexing -… Nicolas Mailhot
- Re: Portal authorization (was: Re: multiplexing -… Nicolas Mailhot
- Re: Portal authorization Julian Reschke
- Re: Portal authorization Julian Reschke
- Re: Portal authorization Nicolas Mailhot
- Re: Portal authorization Julian Reschke
- Re: multiplexing -- don't do it Salvatore Loreto
- Re: multiplexing -- don't do it Amos Jeffries
- Re: Portal authorization Amos Jeffries