[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-httpd-dev
Subject:    Re: svn commit: r1897872 - in /httpd/httpd/trunk: changes-entries/http2_request_scheme.txt modules/h
From:       Stefan Eissing <stefan () eissing ! org>
Date:       2022-02-10 11:04:42
Message-ID: 8E5105D8-E58E-4B7A-9F19-4EFA520F5FF2 () eissing ! org
[Download RAW message or body]



> Am 10.02.2022 um 00:57 schrieb Roy T. Fielding <fielding@gbiv.com>:
> 
> > On Feb 9, 2022, at 1:28 AM, Stefan Eissing <stefan@eissing.org> wrote:
> > > Am 09.02.2022 um 10:15 schrieb Ruediger Pluem <rpluem@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.

I hope I got this right in r1897940 now. The gist of the change now is:
- h2 does not deny any :scheme value from becoming a request
- :scheme values that do not match the main connection scheme are forwarded
 in r->the_request as absolute uri to being processed by the generic 
 HTTP protocol parsing iun ap_parse_request_line(r).
- RFC 7540 requirements on CONNECT method have been added and these also
 use the absolute uri in r->the_request

Kind Regards,
Stefan


[prev in list] [next in list] [prev in thread] [next in thread]