RE: SETTINGS_MIXED_SCHEME_PERMITTED | Re: I-D Action: draft-ietf-httpbis-http2-encryption-07.txt

Well, origin includes scheme, so yes -- if it's terminating HTTP and switching on origin, that means it's looking at the scheme.  That doesn't imply it needs to pass through the MIXED_SCHEME or whatever from the back-end, since it will have its own connections to the back-end servers.  Those will control whether the reverse proxy can mix scheme in its connections to the back end servers, but that doesn't affect whether it supports a mixed scheme on its front.  It will have a potentially-complex set of rules on what requests get served from which back-end server and how.

If it's just a load balancer, possibly terminating TLS, then the HTTP connection terminates at a single back-end, which either supports a mix or not.  In this case, the load balancer would be switching on hostname, not origin, if that.

As to the last, my point is that this document is describing how an alternative can indicate that it doesn't have the problems called out in RFC 7838 section 9.5.  But that section already says, in effect, "don't point to an alternative that has this problem."  So I'm not clear what new additional information is being conveyed here, other than that the origin's Alt-Svc header wasn't sent in error.

(ELI5 => "Explain Like I'm 5" => give me a very simple explanation)

-----Original Message-----
From: hurtta@siilo.fmi.fi [mailto:hurtta@siilo.fmi.fi] On Behalf Of Kari Hurtta
Sent: Wednesday, October 5, 2016 12:34 PM
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>; Martin Thomson <martin.thomson@gmail.com>; Patrick McManus <mcmanus@ducksong.com>; HTTP working group mailing list <ietf-http-wg@w3.org>
Subject: Re: SETTINGS_MIXED_SCHEME_PERMITTED | Re: I-D Action: draft-ietf-httpbis-http2-encryption-07.txt

Mike Bishop <Michael.Bishop@microsoft.com>: (Wed Oct  5 20:28:20 2016)
> I'm having trouble envisioning the scenario where you need to split this by origin, though.  Our concerns here are about server implementations that ignore the scheme component and simply rely on the incoming port to provide that information, right?.  That means you need to get that information on a port-by-port (i.e. server/connection) basis.  Is there a scenario where alternate.example.com:443 is capable of parsing mixed-scheme requests for one origin, but blind to it for another?  Here are the cases I can think of:
> 
>   - Actual server with multiple origins:  It may or may not be configured to *serve* http:// scheme for all origins from that port, but that's indicated by the Alt-Svc headers pointing to it.  Mistaken requests would get a 421.
>   - TLS-terminating load balancer:  The connection inside TLS will still reach a single back-end server, so see previous item.
>   - HTTP reverse proxy:  The sites behind it may indeed have different capabilities, but that's strictly a function of how the reverse proxy obtains the resources, not something the client needs to validate.

This is seemingly about that part of my comment:

  >> connection apply probably for several origins. TLS connection
  >> may be terminated by reverse proxy. And different origins
  >> are served by different processes or servers behind of
  >> reverse proxy.
  >>
  >> I guess that SETTINGS_MIXED_SCHEME_PERMITTED is too wide.

Yes, that depends what you want validate.

I was envisioning that selection of back end server spool on reverse proxy / load balancer is function of origin.

( Yes, this imply that TLS is terminated here )

Effectively you are saying that selection of back end server spool on reverse proxy / load balancer must be function of origin AND scheme. Or that that reverse proxy / load balancer must check scheme.

Yes, it is possible to require that SETTINGS_MIXED_SCHEME_PERMITTED is not sent if reverse proxy / load balancer does not check itself scheme.

If reverse proxy / load balancer checks scheme and found that http: is used, it need get SETTINGS_MIXED_SCHEME_PERMITTED from backend server (if HTTP/2 is used) or use white list for secure backend servers / pools or refuse request.

White list tells that which backend servers / pools check scheme, in that case http:  -request can be sent ot here.

If selection of back end server / server pool is function of origin AND scheme, then request can be sent to that server / pool which is for http: -scheme.


> Again, that's RFC 7838 ("mitigate ... by refraining from advertising alternative services for insecure schemes.").

That is

|   refraining from advertising alternative services for insecure schemes
|   (for example, HTTP).


And whole draft is about advertising alternative services for
http -scheme.

I'm really confused.

> Can someone ELI5?

I do not found that from dictionary.

/ Kari Hurtta

Received on Wednesday, 5 October 2016 19:54:33 UTC