> Am 10.02.2022 um 00:57 schrieb Roy T. Fielding <field...@gbiv.com>:
>
>> 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.
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
