W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

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

From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 2 Nov 2016 17:13:38 +1100
Message-ID: <CABkgnnUL+AJEi=92K95f22vrx17Rmm0j1rEahhwu-my3DPcEwA@mail.gmail.com>
To: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Cc: HTTP working group mailing list <ietf-http-wg@w3.org>
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.

Let's say that we have a gateway that routes based on the first
request, there's not really much that the gateway does that will
prevent the origin server from receiving a request for the .well-known
resource.  If the origin server is still stupid enough to provide a
positive response - for an origin that it shouldn't be expecting to be
serving requests for - then I don't think there is any way that they
can be helped.

If a gateway routes on path, and .well-known goes to a server that
advertises op-sec, and other resources don't, that's pathological.

If the gateway routes on almost every request, but occasionally gets
lazy, that's pathological.
Received on Wednesday, 2 November 2016 06:14:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 November 2016 06:14:14 UTC