> On Feb 9, 2022, at 1:28 AM, Stefan Eissing <ste...@eissing.org> wrote: >> Am 09.02.2022 um 10:15 schrieb Ruediger Pluem <rpl...@apache.org>: >> On 2/8/22 7:10 PM, Roy T. Fielding wrote: >>> As noted in >>> >>> https://github.com/icing/mod_h2/issues/230#issuecomment-1032905432 >>> >>> This doesn't look right to me. I think what you want is to verify that >>> https is >>> in a secured connection. This should have no effect on other schemes, and >>> certainly not require all schemes to be http or https. >>> >>> Literally, the scheme is a naming system, not a protocol. "http" and "https" >>> and "foo" schemes can be resolved by any protocol that performs requests >>> on an absolute URI, including HTTP/2. "https" only requires the connection >>> to be secured end-to-end. >> >> With respect to our HTTP/1 handling r1895921 >> http://svn.apache.org/viewvc?view=revision&revision=1895921 added >> a check that the scheme for non forward proxied requests either needs to be >> http or https, but we don't check >> for a matching with the actual connection whether this is secured or not. > > Thanks for pointing that out, Ruediger. I think I need to change mod_http2 to > populate the uri.scheme when a :scheme header was sent in the request. Then > we have the check in one place. > > The question with matching "http" and "https" concerns: > A. do we select the correct server_rec matching the scheme? > B. do we want to deny access to https: resources on a non-secured connection? > > I'll add a test for A. My opinion on B is that we should. > > Kind Regards, > Stefan
The problem with B is that the TLS parts may have already been removed by a trusted gateway or TLS offload device. I don't know how we recognize that in our own server config, if at all. Basically, we need the config to state that the service URL is https even though the message is just http, and we need to be sure that the above check can be overridden by such a config. And don't forget that proxies can also receive ftp, ftps, doi, and urn as schemes, depending entirely on how the modules are mapped and what kinds of clients are being serviced. It's important to keep in mind that IETF specs only define the protocol as it crosses the Internet. Our server also has to support network configs for inside a colo, non-TCP networks, localhost, and symmetric cyphers, etc. Hence, some of the TLS-only requirements have no meaning to us outside the default config, and shouldn't be enforced by the protocol module. ....Roy
