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

[Erik Nygren <[e-mail]>]

On Wed, Nov 2, 2016 at 2:13 AM, Martin Thomson <[e-mail]>
wrote:

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