Re: 2.2. Interaction with "https" URIs | Re: Op-sec simplification

Kari Hurtta <hurtta-ietf@elmme-mailer.org> Thu, 03 November 2016 18:36 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 0D021129993 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 3 Nov 2016 11:36:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.398
X-Spam-Level:
X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 eta9LDT4UwhF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 3 Nov 2016 11:36:26 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 096C812951B for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 3 Nov 2016 11:36:24 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1c2Mo6-0002iT-TK for ietf-http-wg-dist@listhub.w3.org; Thu, 03 Nov 2016 18:32:10 +0000
Resent-Date: Thu, 03 Nov 2016 18:32:10 +0000
Resent-Message-Id: <E1c2Mo6-0002iT-TK@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <hurtta@siilo.fmi.fi>) id 1c2Mo2-0002eU-Np for ietf-http-wg@listhub.w3.org; Thu, 03 Nov 2016 18:32:06 +0000
Received: from smtpvgate.fmi.fi ([193.166.223.36]) by mimas.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from <hurtta@siilo.fmi.fi>) id 1c2Mnw-0007Ir-28 for ietf-http-wg@w3.org; Thu, 03 Nov 2016 18:32:01 +0000
Received: from souk.fmi.fi (souk.fmi.fi [193.166.211.113]) (envelope-from hurtta@siilo.fmi.fi) by smtpVgate.fmi.fi (8.13.8/8.13.8/smtpgate-20161014/smtpVgate) with ESMTP id uA3IVQII002186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Nov 2016 20:31:26 +0200
Received: from shell.siilo.fmi.fi by souk.fmi.fi with ESMTP id uA3IVQ7W017006 ; Thu, 3 Nov 2016 20:31:26 +0200
Received: from shell.siilo.fmi.fi ([127.0.0.1]) by shell.siilo.fmi.fi with ESMTP id uA3IVPr9016034 ; Thu, 3 Nov 2016 20:31:25 +0200
Received: by shell.siilo.fmi.fi id uA3IVN8R016033; Thu, 3 Nov 2016 20:31:23 +0200
Message-Id: <201611031831.uA3IVN8R016033@shell.siilo.fmi.fi>
In-Reply-To: <CAKC-DJiGp3g26nDZJg4tor4B7-om+BZZp=Hgp4JXNik_ibDPkQ@mail.gmail.com>
References: <20161031053239.E9C6D12F5D@welho-filter3.welho.com> <20161101172202.BE19F12310@welho-filter1.welho.com> <CABkgnnWhcp_tVx9M9FTOdSF-U5EoAzdNNVZaYzjdxUGhHydX7w@mail.gmail.com> <201611020548.uA25m4Wm026906@shell.siilo.fmi.fi> <CABkgnnUL+AJEi=92K95f22vrx17Rmm0j1rEahhwu-my3DPcEwA@mail.gmail.com> <CAKC-DJiGp3g26nDZJg4tor4B7-om+BZZp=Hgp4JXNik_ibDPkQ@mail.gmail.com>
To: Erik Nygren <erik@nygren.org>
Date: Thu, 3 Nov 2016 20:31:23 +0200 (EET)
Sender: hurtta@siilo.fmi.fi
From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
CC: Martin Thomson <martin.thomson@gmail.com>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>, HTTP working group mailing list <ietf-http-wg@w3.org>
X-Mailer: ELM [version ME+ 2.5 PLalpha43]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
X-Filter: smtpVgate.fmi.fi: 3 received headers rewritten with id 20161103/46182/01
X-Filter: smtpVgate.fmi.fi: ID 46189/01, 1 parts scanned for known viruses
X-Filter: souk.fmi.fi: ID 0938/01, 1 parts scanned for known viruses
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (smtpVgate.fmi.fi [193.166.223.36]); Thu, 03 Nov 2016 20:31:28 +0200 (EET)
Received-SPF: none client-ip=193.166.223.36; envelope-from=hurtta@siilo.fmi.fi; helo=smtpVgate.fmi.fi
X-W3C-Hub-Spam-Status: No, score=-6.1
X-W3C-Hub-Spam-Report: AWL=0.116, BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.305, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1c2Mnw-0007Ir-28 6db6a8f5c8f31ae39b95b14cf18477d2
X-Original-To: ietf-http-wg@w3.org
Subject: Re: 2.2. Interaction with "https" URIs | Re: Op-sec simplification
Archived-At: <http://www.w3.org/mid/201611031831.uA3IVN8R016033@shell.siilo.fmi.fi>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32842
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>

Erik Nygren <erik@nygren.org>rg>: (Wed Nov  2 22:02:38 2016)
> On Wed, Nov 2, 2016 at 2:13 AM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
> 
> > On 2 November 2016 at 16:48, Kari Hurtta <hurtta-ietf@elmme-mailer.org>
> > wrote:
> > > In these cases on these bad examples that http: -probe determined
> > > routing.  I guess that bad examples are NOT concern for op-sec, but it
> > > may be concern for browser (some secure cookie is then served
> > > to http: -routing for example when broser sent it to for
> > > https: -scheme).
> >
> > I'm willing to say that (contrary to previously-held opinions), that
> > this is a risk that is worth taking.  If we find that the probe
> > triggers a bad route AND that bad route responds favourably to that
> > probe, THEN we have to assume that the bad route is smart enough to
> > handle requests with a slightly odd scheme.
> >
> 
> It's not just the "confusion" factor.  There are other reasons why a server
> operator may not want mixed-scheme (ie, mixed origin) on the same
> connection.  Clients must at least expect that a server will 421 for
> mixed-scheme on a connection, and the perf impact and bug risk from this
> could be a blocker to some using Opp Sec.
> 
> An example of why this could be bad would be a CDN server that terminates
> both HTTP and HTTPS over TLS but demuxes them such that HTTPS requires TLS
> to content origin but HTTP is allowed to go cleartext to content origin.
> When a single TLS connection demuxes to a mixture of TLS and cleartext
> traffic, this feels like asking for increased trouble and attack surfaces.
> Prohibiting mixed-scheme on the incoming connection makes this feel much
> safer.
> 
> Another example would be client cert authentication for HTTPS requests
> against a TLS connection.  Having these also apply to HTTP requests feels
> "weird" somehow (and could be another attack surface).
> 
>       Erik

Hmm.  

Simplest /.well-known/http-opportunistic response, which
includes that functionlity, contains object as root.

Member names are origins.  Members have string
either "mixed-scheme" or "distinct-scheme" as value.

If origin member have value "mixed-scheme" then 
client may use same connection for "http" and
"https" requests.

If origin member have value "distinct-connection"
then client must reserve distict connection for
http requests of Opportunistic Security. Where
that connection is not used for other purposes
(for example normal "https" requests).

If origin member have some other value, then
this specification does not define semantic
for it. Client should not use opportunic
security for that origin unless client
does not know semantic of that origin member
value.

Example is

   GET http://example.com/.well-known/http-opportunistic HTTP/1.1
   Host: example.com

   HTTP/1.1 200 OK
   Content-Type: application/json
   Connection: close

   {
     "http://www.example.com": "mixed-scheme",
     "http://example.com": "distinct-connection"
   }

/ Kari Hurtta