Re: Httpd security reveals
On Mon, Jan 2, 2017 at 11:49 PM, Eric Covener wrote: > On Mon, Jan 2, 2017 at 11:48 PM, William A Rowe Jr > wrote: >> So, Jacob and I... He did most of the grunt work, I only pushed off the >> underlying premise... Have a very very long list of real and potential >> security patches. >> >> I am asking publicly of (often obstanant) httpd pmc folks, do we proceed >> without a 2.2 mitigation? Those in the know, already know. >> >> Happy to RM Wed a.m. if we have the votes. > > Sorry, I totally missed that you had completed/proposed the backport > of the showstopper to 2.2.x. I should have reviewed it earlier but I > will work on it Tuesday. Clarification, I completed 'a' proposal, and reordered a number of other accepted backports to incorporate all of work in sequence. As Yann had pointed out 'patch doesn't apply'... when it was all disordered. There are a couple additions in the past week that should be considered from the 2.4.x-http-strict branch, but the patch has been complete for some time. Cheers, Bill
Re: Httpd security reveals
On Mon, Jan 2, 2017 at 11:48 PM, William A Rowe Jr wrote: > So, Jacob and I... He did most of the grunt work, I only pushed off the > underlying premise... Have a very very long list of real and potential > security patches. > > I am asking publicly of (often obstanant) httpd pmc folks, do we proceed > without a 2.2 mitigation? Those in the know, already know. > > Happy to RM Wed a.m. if we have the votes. Sorry, I totally missed that you had completed/proposed the backport of the showstopper to 2.2.x. I should have reviewed it earlier but I will work on it Tuesday. My preference would be to proceed with the release once the current showstopper is in, and not to wait for further mitigations or patches. I don't think undisclosed vulnerability fixes are imminent and we have an important, disclosed CVE to ship. -- Eric Covener cove...@gmail.com
Httpd security reveals
So, Jacob and I... He did most of the grunt work, I only pushed off the underlying premise... Have a very very long list of real and potential security patches. I am asking publicly of (often obstanant) httpd pmc folks, do we proceed without a 2.2 mitigation? Those in the know, already know. Happy to RM Wed a.m. if we have the votes.
[proposed] 2.4 Maintenance SIG
So far, discussions are polarized on a single axis... East: Let's work on 3.0; whatever is going on in 2.4 won't distract me, I won't spend time reviewing enhancements, because 3.0 is the goal. West: Let's keep the energy going on 2.4 enhancements, I won't spend time on 3.0 usability because it isn't ready or necessary. There is a disconnect, because 'East' folks can't actually put up with the breakage introduced by enhancements they can't review on 2.4, but all feel responsible to keeping 2.4 usable to EOL. So I'd like to know, in light of a perpetual chain of (often build and/or run-time breaking regression) enhancements, if there is support for a 2.4.24.x release chain during the 3.0 transition? And support for potentially 3x backports to 2.4.x, 2.4.24.x and 2.2.x, of really serious bug fixes? It's clear this project doesn't agree, so the question twists to how we agree to disagree.
Re: HTTP/2 frame prioritization not honored
Thanks Stefan! I just tried the tweaked version. I think I am seeing similar behavior, i.e. the higher-prio HTML reply is sent ~500ms after its request is received, writing ~500 lower-prio DATA frames (~7.5MB) in the meantime. Before any conclusions, I wanted to make sure I compiled/used the tweaked mod properly with my existing Apache/2.4.25 on Ubuntu, since I haven't done the process before: I couldn't find details on the right way to swap in/out module versions, so I ended up compiling v.1.8.6 and pointing to the created mod_http2.so in "/etc/apache2/mods-enabled/http2.load", but I'm really not sure that's the right way. The only way I verified it was seeing this in /var/log/apache2/error.log: "[http2:info] [pid 24935] AH03090: mod_http2 (v1.8.6-git, feats=CHPRIO+SHA256+INVHD, nghttp2 1.17.0), initializing..." Assuming this is an acceptable way to use the tweaked version of the module (please let me know if not), where should I share two apache log files (one trace for each module version) so you could verify what I see? A few relevant lines from the v1.8.6 run (similar to the stable module, AFAICT): [Mon Jan 02 13:59:59.636519 2017] [http2:debug] [pid 26718] h2_session.c(439): [client ] AH03066: h2_session(0): recv FRAME[HEADERS[length=39, hend=1, stream=19, eos=1]], frames=13/1721 (r/s) [Mon Jan 02 13:59:59.637099 2017] [http2:debug] [pid 26718] h2_task.c(106): [client ] AH03348: h2_task(0-19): open output to GET /preposition/nextnav.html [ ... continue sending ~500 DATA frames for streams 7-11 ...] [Mon Jan 02 14:00:00.177350 2017] [http2:debug] [pid 26718] h2_session.c(661): [client ] AH03068: h2_session(0): sent FRAME[HEADERS[length=87, hend=1, stream=19, eos=0]], frames=16/2209 (r/s) [Mon Jan 02 14:00:00.177366 2017] [http2:debug] [pid 26718] h2_session.c(661): [client ] AH03068: h2_session(0): sent FRAME[DATA[length=456, flags=1, stream=19, padlen=0]], frames=16/2210 (r/s)8.6 [ ... continue sending streams 11 onwards ...] Thanks! On Sat, Dec 31, 2016 at 5:43 AM, Stefan Eissing < stefan.eiss...@greenbytes.de> wrote: > Hi Kyriakos, > > have a look at https://github.com/icing/mod_h2/releases/tag/v1.8.6 > > That version flushes when at least 2 TLS records are ready to send. Also, > frame sizes are now aligned to TLS record sizes. So they are influenced by > the H2TLSWarmUpSize and H2TLSCoolDownSecs settings. > > Additionally, and highly experimental, I added H2TLSFlushCount to > configure the number of records to flush. You may play around with it > (default is 2) in your scenarios. > > I hope that this reduces buffering and makes the server more (another word > for agile, pls) to stream changes. Please let me know if that had any > effect on your tests. > > Thanks, > > Stefan > > > Am 29.12.2016 um 12:40 schrieb Kyriakos Zarifis : > > > > That means the images should get a minim of ~30% of the available > bandwidth as long as they have data. My reading. > > > > Right. Makes sense. > > Stefan Eissing > > bytes GmbH > Hafenstrasse 16 > 48155 Münster > www.greenbytes.de > >
Re: ERR_SPDY_PROTOCOL_ERROR - additional info
On 2017-01-02 10:50, Stefan Eissing wrote: > Are these public facing servers? Do you have low traffic instances where to > enable super-verbose log level and make a test request? Of interest would be Yes, they are and that's why I had to fix the issue right away. I deactivated h2 so that people could reach the subdomains again. The strange thing is that it did not happen on all subdomains. As I said, the error even happened on an Alias. e.g.: server.com worked server.com/test did not work > LogLevel http2:trace2 > LogLevel ssl:trace2 > LogLevel core:debug > > That log should then give an idea of what is going on. Thanks. Ok, let me create a few dummy subdomains. Hopefully the problem is reproducible and I can get you the data you need. Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: Automated tests
Luca Toscano wrote on Mon, Jan 02, 2017 at 15:51:43 +0100: > I don't have a wide experience on build httpd on systems different than > Debian/Ubuntu, so any help/suggestion/pointer would help a lot (for > example, building on Windows). I wouldn't worry about that just yet. Start by having only an Ubuntu bot; that'd already be a step forward. Let someone who builds on Windows be the liaison with infra about a Windows buildslave. Setting this up isn't a lot more complicated than filing an INFRA ticket with a build script, a list of build dependencies, and a list of branches to build, and deciding how build failures would be notified. Cheers, Daniel
Re: ERR_SPDY_PROTOCOL_ERROR - additional info
Are these public facing servers? Do you have low traffic instances where to enable super-verbose log level and make a test request? Of interest would be LogLevel http2:trace2 LogLevel ssl:trace2 LogLevel core:debug That log should then give an idea of what is going on. Thanks. -Stefan > Am 02.01.2017 um 16:47 schrieb Helmut K. C. Tessarek : > > On 2017-01-02 04:58, Stefan Eissing wrote: >> You get the errors using Chrome? What does Firefox say? > > On Firefox I only got some unspecified error (the page was not > rendered). That's why I switched to Chrome to get at least some info. > >> There is one new feature in 2.4.25, off by default, that causes such >> errors with Chrome. The Chrome bug report has status "fixed", not >> sure when it will be released >> (https://bugs.chromium.org/p/chromium/issues/detail?id=662197). > > Nope, this error happens with all browsers. > >> As I said, this behaviour is off by default for this reason. It is >> changed by directive "H2EarlyHints". >> >> But maybe it's something totally unrelated to this. Are you able to >> reproduce this on a non-production server of yours? > > Unfortunately I don't have another Linux server with the same > configuration. I could try to create a few dummy sub domains and see if > it happens again. But I still need info how to debug this any further. > > Cheers, > K. C. > > -- > regards Helmut K. C. Tessarek > lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D > > /* > Thou shalt not follow the NULL pointer for chaos and madness > await thee at its end. > */ Stefan Eissing bytes GmbH Hafenstrasse 16 48155 Münster www.greenbytes.de
Re: ERR_SPDY_PROTOCOL_ERROR - additional info
On 2017-01-02 04:58, Stefan Eissing wrote: > You get the errors using Chrome? What does Firefox say? On Firefox I only got some unspecified error (the page was not rendered). That's why I switched to Chrome to get at least some info. > There is one new feature in 2.4.25, off by default, that causes such > errors with Chrome. The Chrome bug report has status "fixed", not > sure when it will be released > (https://bugs.chromium.org/p/chromium/issues/detail?id=662197). Nope, this error happens with all browsers. > As I said, this behaviour is off by default for this reason. It is > changed by directive "H2EarlyHints". > > But maybe it's something totally unrelated to this. Are you able to > reproduce this on a non-production server of yours? Unfortunately I don't have another Linux server with the same configuration. I could try to create a few dummy sub domains and see if it happens again. But I still need info how to debug this any further. Cheers, K. C. -- regards Helmut K. C. Tessarek lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: Automated tests
Hi Stefan, 2016-12-30 23:55 GMT+01:00 Stefan Fritsch : > > > Another thing that is missing: A buildbot that builds current trunk (and > possibly 2.x branches) and runs the test suite and alerts the dev list of > regressions. I guess this "just" needs a volunteer to set it up and > document > it and the ASF would provide the infrastructure. > I agree 100% with Jacob, but this particular bit is something that I can try to do. Not sure how feasible it would be to run the test suite, but definitely we'd need something that simply builds httpd after each commit on the major branches (2.2.x, 2.4.x, trunk). I don't have a wide experience on build httpd on systems different than Debian/Ubuntu, so any help/suggestion/pointer would help a lot (for example, building on Windows). Thanks! Luca
Re: About httpd project
Hi Amol, 2017-01-01 19:42 GMT+01:00 Amol Holani : > Hi, > I want to work on this project. > The subtask - Improve the Request Processing guide. > But I am beginner in this area, so please guide me in proceeding with the > project. > > please check [1], in which a similar question was asked a while ago. Thanks for your interest! Luca [1]: https://lists.apache.org/thread.html/7c40cd1375775828da7ffb2b6ead33d7dbbd56d2fc51d5a5428b22b2@1463597382@%3Cdev.httpd.apache.org%3E
Configuration of trusted OCSP responder certificates
Hi devs, I'd like to enquire about the possibilities to merge the patch to support configuring trusted OCSP responder certificates. We need this change in order to be able to use OCSP with client certificate authentication. The patch is in https://bz.apache.org/bugzilla/show_bug.cgi?id=46037 for a few years now and there have been several reports of it working without problems; we're also running it for a few years and it works fine for us. What can we do to get this merged? Cheers, Thijs Kinkhorst SURFnet bv signature.asc Description: OpenPGP digital signature
Re: ERR_SPDY_PROTOCOL_ERROR - additional info
You get the errors using Chrome? What does Firefox say? There is one new feature in 2.4.25, off by default, that causes such errors with Chrome. The Chrome bug report has status "fixed", not sure when it will be released (https://bugs.chromium.org/p/chromium/issues/detail?id=662197). As I said, this behaviour is off by default for this reason. It is changed by directive "H2EarlyHints". But maybe it's something totally unrelated to this. Are you able to reproduce this on a non-production server of yours? Thanks, Stefan > Am 01.01.2017 um 23:23 schrieb Helmut K. C. Tessarek : > > I'm sorry that the previous mail was so short, but there are no error > messages in the error log. It happens on several subdomains and for > aliases within the same domain, which makes no sense to me, especially > since I never came across this problem with the previous httpd version. > > I'm using the following directive: Protocols h2 http/1.1 > > I had to deactivate h2 altogether, because a lot of subdomains and > aliases errored out and were not reachable. I could have also reverted > back to 2.4.23, which I will probably do in a couple of days. > > I couldn't do any problem determination on my production server. I had > to make it work asap. > > I just wanted to mention that there's something off with h2. > > Since I only upgraded httpd from 2.4.23 to 2.5.25 w/o changing any > configuration files, it must be a problem with the current h2 > implementation. > > Cheers, > K. C. > > -- > regards Helmut K. C. Tessarek > lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D > > /* > Thou shalt not follow the NULL pointer for chaos and madness > await thee at its end. > */ Stefan Eissing bytes GmbH Hafenstrasse 16 48155 Münster www.greenbytes.de
