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

Erik Nygren <> Wed, 02 November 2016 20:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C56A61298AF for <>; Wed, 2 Nov 2016 13:07:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.397
X-Spam-Status: No, score=-8.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KvYd9b7_hZXU for <>; Wed, 2 Nov 2016 13:07:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C0F021298A9 for <>; Wed, 2 Nov 2016 13:07:43 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c21kj-0007Aq-IC for; Wed, 02 Nov 2016 20:03:17 +0000
Resent-Date: Wed, 02 Nov 2016 20:03:17 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c21ke-00077l-8Y for; Wed, 02 Nov 2016 20:03:12 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1c21kX-0003Fp-Q7 for; Wed, 02 Nov 2016 20:03:06 +0000
Received: by with SMTP id t125so22649853ywc.1 for <>; Wed, 02 Nov 2016 13:02:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+ZKWwlWeHou/jbDU1jBOMdNat3xhxhiU33TH86OeXmg=; b=KTtfU9y8sNM/1xdheMy1an6IOUsTqNzUaMgmy2s/1qukkTzAfzVgFmlOPkSXW4VUQT 9V2/ut5s8eQKQrRRFAPsYJyULri8nnAqdbR0Ab0X2wb2E0uRHlObe02VbygkHC84NAmO 1MqLzuVpjg5bsPaw8S1r78G8/fealPUWeobxiOnbUn9DyXeRtg2N9LEJbBA3qD/xOBp4 9KActCKcdv1vHehJjp1tECY4j/2hK5igAV7jw4Zh3bup/wRwUeI3mZ1sRjXzcjuBntqp Ds1tfNnEh6CGywbN72UxerfWG9wPTPAyUQZj6S99aC7udUAvwiMWHhbOHRodMb+iX6wU hp6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+ZKWwlWeHou/jbDU1jBOMdNat3xhxhiU33TH86OeXmg=; b=XdL60O59f5OwRBI+0PmolstDESct+WbXcBHRlmRaKY1OlF+oDH/ctRZB+IqRjETsZI R7d8r2QrL2Xu9tjursmlFBb3s0YKSh9GLOtXdinb3Tao2cNpcSB1tUXlNl+WCGjYoYw7 QxVoMOcKp0k/hlhusr9L6/2v7/3dt1rbHSGEIXT3kGQ0KKGLMZe0dz+PyYhYHZd74UuG neYnGCTgFKcfsogH5eb/76UBuiYqlUkNK+58J8i5tw3oF4AmzFkMULi4cJrfn8Fwnfte nnrCnaPNBkK2r+DWg1zwmKaO54cwE+GAV9Cwt7RcItrswZOH/ckp7n9DmzPm7aT5DrwL BMMg==
X-Gm-Message-State: ABUngvcYtUe+8hiFWlyRUGXXZtYf3/DJHbbZwr3bQdJhw1av7D7S3p9NRXA+ZF9/hJYV31T9kJDpGPKqWQvltA==
X-Received: by with SMTP id 195mr3976657itt.90.1478116959628; Wed, 02 Nov 2016 13:02:39 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 2 Nov 2016 13:02:38 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Erik Nygren <>
Date: Wed, 2 Nov 2016 16:02:38 -0400
X-Google-Sender-Auth: Y1HdevtAmQNu1Wfr1dBgy2QQ1NE
Message-ID: <>
To: Martin Thomson <>
Cc: Kari Hurtta <>, HTTP working group mailing list <>
Content-Type: multipart/alternative; boundary=001a1144847450b464054056eced
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.9
X-W3C-Scan-Sig: 1c21kX-0003Fp-Q7 4be4a6bfb705d98845bced77cd259f96
Subject: Re: 2.2. Interaction with "https" URIs | Re: Op-sec simplification
Archived-At: <>
X-Mailing-List: <> archive/latest/32820
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Wed, Nov 2, 2016 at 2:13 AM, Martin Thomson <>

> On 2 November 2016 at 16:48, Kari Hurtta <>
> 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

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).