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

[Kari Hurtta <[e-mail]>]

Martin Thomson <[e-mail]>: (Wed Nov  2 02:52:35 2016)
> On 2 November 2016 at 04:22, Kari Hurtta <[e-mail]> wrote:
> >         • No concern; that check that http://{...}/.well-known/http-opportunistic
> >           succeed tells enough that there is no confusion
> 
> I think that this is sufficient.
> 
> The reason that I think this is OK, and the reason for removing a
> mixed-scheme flag was that the risk comes from confusion.  That
> confusion exists as soon as an http:// request is made over a TLS
> connection.
> 
> It's not that much worse when things are mixed.  The bad examples of
> routing based on the first request are bad for many reasons.  They are
> simply cause to NOT provide the .well-known resource.

Except of course on case where that .well-known was the first request.

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

In theses case they do not mess http: prosessing.

I asked earlier that

https://lists.w3.org/Archives/Public/ietf-http-wg/2016OctDec/0104.html

was that routing based on the first request  only concern:

| Is reason that
| 	∘ confusion happens if "http" follows "https", or 
|	∘ scheme is determined only on first request ?

You answered 
https://lists.w3.org/Archives/Public/ietf-http-wg/2016OctDec/0105.html

| The point of this is to cover off any problems that might arise from
| connection reuse.  It's clumsy. 

and

| we're incapable of detecting all cases where the server decides to do
| crazy things - I'm sure that I can devise a server architecture that
| will fail for any solution we devise - we have to instead take steps
| that we think are reasonable.

 
> >         • Forbid using same connection for "http" requests
> >           which would ordinarily be used for "https" requests.
> 
> We've already established that this is difficult to define properly.
> And it's unnecessarily limiting.
> 
> >         • Forbid using same connection for "http" requests
> >           which would ordinarily be used for "https" requests
> >           but allow it if there is "mixed-scheme" -member (or
> >           some other flag).
> 
> As above.
> 
> >         • Forbid using same connection for "http" requests
> >           which would ordinarily be used for "https" requests
> >           unless same connection which was tested
> >           for http://{...}/.well-known/http-opportunistic
> >           are also after that tested:
> >
> >                 ∘ That https requests for /.well-known/http-opportunistic
> >                   on same host {...} does not return same object
> >
> >                 ∘ Note that if that test fails, then that connection
> >                   is no longer be good for http requests either.
> 
> As above, just more complicated :)

/ Kari Hurtta