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

Erik Nygren <erik@nygren.org>: (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

Received on Thursday, 3 November 2016 18:32:06 UTC