Re: Changing the httpd security process
On 8/20/20 6:24 PM, Joe Orton wrote: > On Mon, Aug 17, 2020 at 12:08:35PM +0100, Joe Orton wrote: >> This roughly reverts the httpd process to what we used prior to adopting >> the Tomcat-esque policy for the whole ASF. We would have to document >> this and possibly need it approved by the ASF security team. > > Thanks to those who have given feedback. > > I won't rush this since it's Summer and people may be on holiday, if by > the start of September there is no dissent I will assume PMC consensus > for making this change and work out how to document & notify security@. > +1 Regards Rüdiger
Re: Changing the httpd security process
> Am 20.08.2020 um 18:24 schrieb Joe Orton : > > On Mon, Aug 17, 2020 at 12:08:35PM +0100, Joe Orton wrote: >> This roughly reverts the httpd process to what we used prior to adopting >> the Tomcat-esque policy for the whole ASF. We would have to document >> this and possibly need it approved by the ASF security team. > > Thanks to those who have given feedback. > > I won't rush this since it's Summer and people may be on holiday, if by > the start of September there is no dissent I will assume PMC consensus > for making this change and work out how to document & notify security@. +1 > Regards, Joe >
Re: Changing the httpd security process
On Mon, Aug 17, 2020 at 12:08:35PM +0100, Joe Orton wrote: > This roughly reverts the httpd process to what we used prior to adopting > the Tomcat-esque policy for the whole ASF. We would have to document > this and possibly need it approved by the ASF security team. Thanks to those who have given feedback. I won't rush this since it's Summer and people may be on holiday, if by the start of September there is no dissent I will assume PMC consensus for making this change and work out how to document & notify security@. Regards, Joe
Re: mod_http2 behavior in case of too many or too large request headers
> Am 20.08.2020 um 11:35 schrieb Ruediger Pluem : > > > > On 8/20/20 10:47 AM, Stefan Eissing wrote: >> >> >>> Am 20.08.2020 um 10:01 schrieb Ruediger Pluem : >>> >>> >>> >>> On 8/19/20 12:18 PM, Stefan Eissing wrote: > Am 19.08.2020 um 12:08 schrieb Ruediger Pluem : > >> >> Understood. I do not see 2. descending from the heavens either and I myself >> am unable/unwilling to work on this. >> >> About hacking this somehow, the options I saw: >> >> a) do the header checking once the request_rec is created and scheduled on a >> secondary connection in a separate thread >> - this means we need to take the billions of header lines into out memory >> first and then schedule a worker to reject it. Seems like begging for a DoS. >> b) create a request_rec on the main connection, trigger the fail on the main >> thread and hope that the response can be buffered and will not block the >> whole h2 handling. Also begging for a DoS. >> c) rewrite the error response handling in the server, which most likely we >> will not be able to port back to 2.4 >> >> Neither of those is attractive in my eyes. Maybe you see another way? > > What about: > > set_error_response would set the http_status in a not yet existing field > (e.g. early_status) > of the h2_request struct via stream->rtmp instead of creating a brigade in > stream->out_buffer and adding to it. > h2_request_create_rec could then check for this field and if non zero call > ap_die after doing some minimal request_rec setup. > I could transform this into a patch for more gory discussion if you like. ;-) a) without making the complete requests, but a special one that knows how to fail? Go for it! cheers, Stefan
Re: mod_http2 behavior in case of too many or too large request headers
On 8/20/20 10:47 AM, Stefan Eissing wrote: > > >> Am 20.08.2020 um 10:01 schrieb Ruediger Pluem : >> >> >> >> On 8/19/20 12:18 PM, Stefan Eissing wrote: >>> >>> Am 19.08.2020 um 12:08 schrieb Ruediger Pluem : > > Understood. I do not see 2. descending from the heavens either and I myself > am unable/unwilling to work on this. > > About hacking this somehow, the options I saw: > > a) do the header checking once the request_rec is created and scheduled on a > secondary connection in a separate thread >- this means we need to take the billions of header lines into out memory > first and then schedule a worker to reject it. Seems like begging for a DoS. > b) create a request_rec on the main connection, trigger the fail on the main > thread and hope that the response can be buffered and will not block the > whole h2 handling. Also begging for a DoS. > c) rewrite the error response handling in the server, which most likely we > will not be able to port back to 2.4 > > Neither of those is attractive in my eyes. Maybe you see another way? What about: set_error_response would set the http_status in a not yet existing field (e.g. early_status) of the h2_request struct via stream->rtmp instead of creating a brigade in stream->out_buffer and adding to it. h2_request_create_rec could then check for this field and if non zero call ap_die after doing some minimal request_rec setup. I could transform this into a patch for more gory discussion if you like. Regards Rüdiger
Re: mod_http2 behavior in case of too many or too large request headers
> Am 20.08.2020 um 10:01 schrieb Ruediger Pluem : > > > > On 8/19/20 12:18 PM, Stefan Eissing wrote: >> >> >>> Am 19.08.2020 um 12:08 schrieb Ruediger Pluem : >>> >>> If mod_http2 detects too many or too large request headers in >>> h2_stream_add_header or h2_stream_end_headers it does not create a >>> pseudo HTTP/1.1 request but directly responds back on the HTTP/2 stream. >>> While this is very efficient from the HTTP/2 perspective >>> it has some bad drawbacks from my perspective: >>> >>> 1. The request is not logged in the access log. >>> 2. Possible custom ErrorDocuments for this status code >>> (HTTP_REQUEST_HEADER_FIELDS_TOO_LARGE, 431) are ignored. >> >> The main reasons (as far as my memory serves) are: >> - that at that time, the whole h1 infrastructure has not been set up yet. >> - reporting on requests and error doc handling is only possible from h1 > > This is my understanding as well. > >> - it seems counter-intuitive to construct and schedule a h1 request for >> something that is not valid input > > I understand that from a developer perspective and as said I see the current > flow as more efficient. On the other hand from a user > perspective it is counter-intuitive if the "same" request behaves differently > whether it is requested via HTTP/1.1 or via HTTP/2. > In the first case it is logged and a custom error page if defined is > returned, in the second case this does not happen. I totally agree. >> >>> I would like to see this changed to have the drawbacks above addressed. >>> Thoughts? >> >> Ceterum censeo: to make all features currently tied to h1 work for other >> protocol, one needs to separate them into a "http" layer that is agnostic to >> the serialization of requests/responses. > > Agreed, but what does this mean? I think we have two ways forward here: > > 1. We continue to hack around this limitation with better or worse hacks that > repeat themselves. > 2. We stop all changes that would require this layer until this layer is in > place. > > While 2. is the cleaner way I doubt that the layer will be availabe any time > soon. Hence 2. would mean to stop some further and > maybe important work on the http2 module. Hence I tend to go for 1., but I am > keen for other opinions or further options that I > missed. Understood. I do not see 2. descending from the heavens either and I myself am unable/unwilling to work on this. About hacking this somehow, the options I saw: a) do the header checking once the request_rec is created and scheduled on a secondary connection in a separate thread - this means we need to take the billions of header lines into out memory first and then schedule a worker to reject it. Seems like begging for a DoS. b) create a request_rec on the main connection, trigger the fail on the main thread and hope that the response can be buffered and will not block the whole h2 handling. Also begging for a DoS. c) rewrite the error response handling in the server, which most likely we will not be able to port back to 2.4 Neither of those is attractive in my eyes. Maybe you see another way? - Stefan
Re: mod_http2 behavior in case of too many or too large request headers
On 8/19/20 12:18 PM, Stefan Eissing wrote: > > >> Am 19.08.2020 um 12:08 schrieb Ruediger Pluem : >> >> If mod_http2 detects too many or too large request headers in >> h2_stream_add_header or h2_stream_end_headers it does not create a >> pseudo HTTP/1.1 request but directly responds back on the HTTP/2 stream. >> While this is very efficient from the HTTP/2 perspective >> it has some bad drawbacks from my perspective: >> >> 1. The request is not logged in the access log. >> 2. Possible custom ErrorDocuments for this status code >> (HTTP_REQUEST_HEADER_FIELDS_TOO_LARGE, 431) are ignored. > > The main reasons (as far as my memory serves) are: > - that at that time, the whole h1 infrastructure has not been set up yet. > - reporting on requests and error doc handling is only possible from h1 This is my understanding as well. > - it seems counter-intuitive to construct and schedule a h1 request for > something that is not valid input I understand that from a developer perspective and as said I see the current flow as more efficient. On the other hand from a user perspective it is counter-intuitive if the "same" request behaves differently whether it is requested via HTTP/1.1 or via HTTP/2. In the first case it is logged and a custom error page if defined is returned, in the second case this does not happen. > >> I would like to see this changed to have the drawbacks above addressed. >> Thoughts? > > Ceterum censeo: to make all features currently tied to h1 work for other > protocol, one needs to separate them into a "http" layer that is agnostic to > the serialization of requests/responses. Agreed, but what does this mean? I think we have two ways forward here: 1. We continue to hack around this limitation with better or worse hacks that repeat themselves. 2. We stop all changes that would require this layer until this layer is in place. While 2. is the cleaner way I doubt that the layer will be availabe any time soon. Hence 2. would mean to stop some further and maybe important work on the http2 module. Hence I tend to go for 1., but I am keen for other opinions or further options that I missed. Regards Rüdiger
