Re: potential TLSv1.3 rproxy issue with openssl 1.1.1 and httpd 2.4.37?
I have a wellness completion benefit package that works good and a budget component that I have registered for and The SSL must remain pure. Assignments have been compiled and are relevant to the assistance progs; Top priority LifeSpan preserved with occupational legitimate safework load environments. On Thu, Nov 1, 2018, 5:42 PM . wrote: > Hey everyone, > >I have an apache http server (version 2.4.37) that is using SSL > (version 1.1.1) to communicate to an F5 back-end through mod_proxy and > mod_proxy_http. > >The server is configured with a SSLProxyProtocol string that allows for > TLSv1.3, and I am seeing an error that looks like the following: > > [Thu Nov 01 20:00:27.687919 2018] [ssl:info] [pid 86604:tid > 47699324180224] [remote PRIVATEIPREDACTED:443] AH01964: Connection to child > 0 established (server PRIVATEDNSNAMEREDACTED:443) > > [Thu Nov 01 20:00:27.687937 2018] [ssl:trace2] [pid 86604:tid > 47699324180224] ssl_engine_rand.c(126): Proxy: Seeding PRNG with 144 bytes > of entropy > > [Thu Nov 01 20:00:27.687999 2018] [ssl:trace4] [pid 86604:tid > 47699324180224] ssl_engine_io.c(1667): [remote PRIVATEIPREDACTED:443] > coalesce: have 0 bytes, adding 675 more > > [Thu Nov 01 20:00:27.688005 2018] [ssl:trace4] [pid 86604:tid > 47699324180224] ssl_engine_io.c(1727): [remote PRIVATEIPREDACTED:443] > coalesce: passing on 675 bytes > > [Thu Nov 01 20:00:27.688009 2018] [ssl:trace3] [pid 86604:tid > 47699324180224] ssl_engine_io.c(1239): [remote PRIVATEIPREDACTED:443] SNI > extension for SSL Proxy request set to 'PRIVATEDNSNAMEREDACTED' > > [Thu Nov 01 20:00:27.688014 2018] [ssl:trace3] [pid 86604:tid > 47699324180224] ssl_engine_kernel.c(2191): [remote PRIVATEIPREDACTED:443] > OpenSSL: Handshake: start > > [Thu Nov 01 20:00:27.688043 2018] [ssl:trace3] [pid 86604:tid > 47699324180224] ssl_engine_kernel.c(2200): [remote PRIVATEIPREDACTED:443] > OpenSSL: Loop: before SSL initialization > > [Thu Nov 01 20:00:27.688293 2018] [ssl:trace4] [pid 86604:tid > 47699324180224] ssl_engine_io.c(2220): [remote PRIVATEIPREDACTED:443] > OpenSSL: write 7/7 bytes to BIO#2b61fc008b80 [mem: 2b61fc027750] (BIO dump > follows) > > [Thu Nov 01 20:00:27.688299 2018] [ssl:trace7] [pid 86604:tid > 47699324180224] ssl_engine_io.c(2143): [remote PRIVATEIPREDACTED:443] > +-+ > > [Thu Nov 01 20:00:27.688302 2018] [ssl:trace7] [pid 86604:tid > 47699324180224] ssl_engine_io.c(2181): [remote PRIVATEIPREDACTED:443] | > : 15 03 01 00 02 02 50 ..P | > > [Thu Nov 01 20:00:27.688304 2018] [ssl:trace7] [pid 86604:tid > 47699324180224] ssl_engine_io.c(2187): [remote PRIVATEIPREDACTED:443] > +-+ > > [Thu Nov 01 20:00:27.688307 2018] [ssl:trace3] [pid 86604:tid > 47699324180224] ssl_engine_kernel.c(22PRIVATEIPREDACTED[remote > PRIVATEIPREDACTED:443] OpenSSL: Write: error > > [Thu Nov 01 20:00:27.688311 2018] [ssl:trace3] [pid 86604:tid > 47699324180224] ssl_engine_kernel.c(2229): [remote PRIVATEIPREDACTED:443] > OpenSSL: Exit: error in error > > [Thu Nov 01 20:00:27.688313 2018] [ssl:info] [pid 86604:tid > 47699324180224] [remote PRIVATEIPREDACTED:443] AH02003: SSL Proxy connect > failed > > [Thu Nov 01 20:00:27.688335 2018] [ssl:info] [pid 86604:tid > 47699324180224] SSL Library Error: error:14228044:SSL > routines:construct_ca_names:internal error > > [Thu Nov 01 20:00:27.688338 2018] [ssl:info] [pid 86604:tid > 47699324180224] [remote PRIVATEIPREDACTED:443] AH01998: Connection closed > to child 0 with abortive shutdown (server PRIVATEDNSNAMEREDACTED:443) > > [Thu Nov 01 20:00:27.688353 2018] [ssl:info] [pid 86604:tid > 47699324180224] [remote PRIVATEIPREDACTED:443] AH01997: SSL handshake > failed: sending 502 > > [Thu Nov 01 20:00:27.688366 2018] [proxy_http:error] [pid 86604:tid > 47699324180224] (PRIVATEIPREDACTED software caused connection abort: > [client PRIVATEIPREDACTED:60171] AH01PRIVATEIPREDACTED error reading status > line from remote server PRIVATEDNSNAMEREDACTED:443 > >This is causing the back-end connection to fail. > >Narrowing the scope of the SSLProxyProtocol string to not allow for TLS > 1.3 relieves the issue and allows proper communication to occur. > >Can anyone else confirm the issue? If so, is there a bug report yet or > would you like me to make one? > >If this is an issue with the release, I would mention that we also saw > a different issue we had to patch ourselves with the apache http server > proxy protocol SSL code between the releases of 2.4.29 and 2.4.33 (there > were security fixes in this release so not upgrading wasn't a great > option), perhaps there could be some additional automated testing for the > use case of an SSL enabled proxy? Unless of course we find I am doing > something stupid at which point disregard that suggestion. > > Thanks, > Dan Oliver >
potential TLSv1.3 rproxy issue with openssl 1.1.1 and httpd 2.4.37?
Hey everyone, I have an apache http server (version 2.4.37) that is using SSL (version 1.1.1) to communicate to an F5 back-end through mod_proxy and mod_proxy_http. The server is configured with a SSLProxyProtocol string that allows for TLSv1.3, and I am seeing an error that looks like the following: [Thu Nov 01 20:00:27.687919 2018] [ssl:info] [pid 86604:tid 47699324180224] [remote PRIVATEIPREDACTED:443] AH01964: Connection to child 0 established (server PRIVATEDNSNAMEREDACTED:443) [Thu Nov 01 20:00:27.687937 2018] [ssl:trace2] [pid 86604:tid 47699324180224] ssl_engine_rand.c(126): Proxy: Seeding PRNG with 144 bytes of entropy [Thu Nov 01 20:00:27.687999 2018] [ssl:trace4] [pid 86604:tid 47699324180224] ssl_engine_io.c(1667): [remote PRIVATEIPREDACTED:443] coalesce: have 0 bytes, adding 675 more [Thu Nov 01 20:00:27.688005 2018] [ssl:trace4] [pid 86604:tid 47699324180224] ssl_engine_io.c(1727): [remote PRIVATEIPREDACTED:443] coalesce: passing on 675 bytes [Thu Nov 01 20:00:27.688009 2018] [ssl:trace3] [pid 86604:tid 47699324180224] ssl_engine_io.c(1239): [remote PRIVATEIPREDACTED:443] SNI extension for SSL Proxy request set to 'PRIVATEDNSNAMEREDACTED' [Thu Nov 01 20:00:27.688014 2018] [ssl:trace3] [pid 86604:tid 47699324180224] ssl_engine_kernel.c(2191): [remote PRIVATEIPREDACTED:443] OpenSSL: Handshake: start [Thu Nov 01 20:00:27.688043 2018] [ssl:trace3] [pid 86604:tid 47699324180224] ssl_engine_kernel.c(2200): [remote PRIVATEIPREDACTED:443] OpenSSL: Loop: before SSL initialization [Thu Nov 01 20:00:27.688293 2018] [ssl:trace4] [pid 86604:tid 47699324180224] ssl_engine_io.c(2220): [remote PRIVATEIPREDACTED:443] OpenSSL: write 7/7 bytes to BIO#2b61fc008b80 [mem: 2b61fc027750] (BIO dump follows) [Thu Nov 01 20:00:27.688299 2018] [ssl:trace7] [pid 86604:tid 47699324180224] ssl_engine_io.c(2143): [remote PRIVATEIPREDACTED:443] +-+ [Thu Nov 01 20:00:27.688302 2018] [ssl:trace7] [pid 86604:tid 47699324180224] ssl_engine_io.c(2181): [remote PRIVATEIPREDACTED:443] | : 15 03 01 00 02 02 50 ..P | [Thu Nov 01 20:00:27.688304 2018] [ssl:trace7] [pid 86604:tid 47699324180224] ssl_engine_io.c(2187): [remote PRIVATEIPREDACTED:443] +-+ [Thu Nov 01 20:00:27.688307 2018] [ssl:trace3] [pid 86604:tid 47699324180224] ssl_engine_kernel.c(22PRIVATEIPREDACTED[remote PRIVATEIPREDACTED:443] OpenSSL: Write: error [Thu Nov 01 20:00:27.688311 2018] [ssl:trace3] [pid 86604:tid 47699324180224] ssl_engine_kernel.c(2229): [remote PRIVATEIPREDACTED:443] OpenSSL: Exit: error in error [Thu Nov 01 20:00:27.688313 2018] [ssl:info] [pid 86604:tid 47699324180224] [remote PRIVATEIPREDACTED:443] AH02003: SSL Proxy connect failed [Thu Nov 01 20:00:27.688335 2018] [ssl:info] [pid 86604:tid 47699324180224] SSL Library Error: error:14228044:SSL routines:construct_ca_names:internal error [Thu Nov 01 20:00:27.688338 2018] [ssl:info] [pid 86604:tid 47699324180224] [remote PRIVATEIPREDACTED:443] AH01998: Connection closed to child 0 with abortive shutdown (server PRIVATEDNSNAMEREDACTED:443) [Thu Nov 01 20:00:27.688353 2018] [ssl:info] [pid 86604:tid 47699324180224] [remote PRIVATEIPREDACTED:443] AH01997: SSL handshake failed: sending 502 [Thu Nov 01 20:00:27.688366 2018] [proxy_http:error] [pid 86604:tid 47699324180224] (PRIVATEIPREDACTED software caused connection abort: [client PRIVATEIPREDACTED:60171] AH01PRIVATEIPREDACTED error reading status line from remote server PRIVATEDNSNAMEREDACTED:443 This is causing the back-end connection to fail. Narrowing the scope of the SSLProxyProtocol string to not allow for TLS 1.3 relieves the issue and allows proper communication to occur. Can anyone else confirm the issue? If so, is there a bug report yet or would you like me to make one? If this is an issue with the release, I would mention that we also saw a different issue we had to patch ourselves with the apache http server proxy protocol SSL code between the releases of 2.4.29 and 2.4.33 (there were security fixes in this release so not upgrading wasn't a great option), perhaps there could be some additional automated testing for the use case of an SSL enabled proxy? Unless of course we find I am doing something stupid at which point disregard that suggestion. Thanks, Dan Oliver
Re: __attribute__
On Thu, Nov 1, 2018 at 3:31 PM Jim Jagielski wrote: > Since __attribute__ is used in various places in trunk and 2.4, is it safe > to assume that I can write something that requires __attribute__(packed)? No ... but surely you meant to write __attribute__((packed)) The real question is... why? It is sorely suboptimal except on x86_64 where the cpu handles the heavy lift ... the compiler must cope with it on MIPS/SPARC/POWER etc, may break atomic updates (our atomics don't protect against this), and doesn't address endianness. It all leads to lots of other questions... https://stackoverflow.com/questions/45116212/are-packed-structs-portable https://stackoverflow.com/questions/8568432/is-gccs-attribute-packed-pragma-pack-unsafe Adding this to any existing public struct definition is not backportable to 2.4.x. A use case would be helpful provide a fair answer to your question.
Re: Stale BZ Bug Tracker reports
To keep this thread moving (additional feedback is welcomed and appreciated)... On Thu, Nov 1, 2018 at 5:03 AM Marion & Christophe JAILLET < christophe.jail...@wanadoo.fr> wrote: > > Le 31/10/2018 à 21:52, William A Rowe Jr a écrit : > > > > There are 715 reports tagged 2.0.0 through 2.3-HEAD of Status NEW or NEEDINFO with no Resolution. > > > > For these bugs I believe we should simply close them with a message that this is a mass-update, that the version is beyond EOL, and a request for reporters/observers to retest and reopen with the supported version number if they are still reproducible using a modern 2.4.x version. But I can't determine the best Status/Resolution code... suggestions? > > +1 > IMHO, the best status would be CLOSED/WONTFIX. Maybe a new Keyword such as TooOldAndInactive to ease finding such mass-update? > Or ask for a new status TOO_OLD (but I'm not sure it would really be that useful) I agree a keyword MassUpdate would be helpful to later identify all tickets closed in any automated way. WONTFIX doesn't seem to fit; 1) a subset of these have been FIXED, 2) a subset are INVALID, 3) there is a WONTFIX subset (applying to 2.5.x as well.) I think a new status is right, perhaps RESOLVED/FUTURE is the best course for the mass-change of these defects that are unlikely to be reviewed by the project community in their present state. They are in fact NEEDINFO (we need info that a) there is a bug and b) it still exists), but since we don't have that as a closure state, RESOLVED/FUTURE seems like the best catch-all. Of course this label is no longer endorsed by the bugzilla team, but they don't seem to have substituted anything else; https://bugs.eclipse.org/bugs/show_bug.cgi?id=178923 So I'd read this as the bug needs to be reproduced with a "later" version of httpd, and is subject to reconsideration "later" on further review, but may have already been resolved in a "later" release. > > There are 69 bugs of status REOPENED, and 20 of status ASSIGNED (?). These should likely be reviewed by hand and either ACCEPTED against 2.4-HEAD, tagged NEEDINFO with a request to re-review (after mass-cleanup of NEEDINFO above), or closed as above with an invitation to retest and reopen. > > +1, after by-hand review, as proposed. > > > There are 255 bugs of Status NEW from 2.4.1-2.4.17, releases which are over three years old. For these, the best resolution is probably NEEDINFO. > > -1. > Not sure NEEDINFO is fine for these ones. We should set NEEDINFO after by hand review, if we NEEDINFO. Or close it if invalid, or leave it as is if it looks right but no one has looked at it. > The reporter has done his job. He has reported what he thinks is enough. WE should provide an answer or ask for more details. You are signing up to reproduce and validate that all of the bugs still exist in the current tree? I agree that reviewing these 255 bugs would be a noble goal, but who is signing up to the task? Will we simply wait until 2.6.0 has been around for a year or two and then reap all the bugs as described above? I propose we do ask for more details, specifically, that their reported bug still exists, on the presumption it is a bug. This merits further discussion, and I'm not moving ahead till we've come to some concensus, but we would do well to decide what we are doing here with the group of 3 to 8 year old flavors of 2.4.x. > > And there are 38 2.4.x NEEDINFO bugs, most of which can likely be closed for good as INVALID under a manual review. > > +1 if older than, let say, 1 year? > The number is small, they could also be doubled check by hand. But is is likely, that it would end as INVALID because the analysis has already been done, and the reporter does not seem to be interested to answer. This number is small, and I am proposing this is a manual effort to either bump the version number perhaps with help from a NEEDINFO request, or closing as INVALID where they are actually not bugs. > > I'm thinking of generic comment which would read (2nd paragraph for 2.0-2.3.x only); > > > > """ > > Please help us to refine our list of open and current defects. This is a mass update of older Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. > > [...]. This is a mass update of old and inactive reports [...] > > > As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. > > > > If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [
__attribute__
Since __attribute__ is used in various places in trunk and 2.4, is it safe to assume that I can write something that requires __attribute__(packed)?
Re: Stale BZ Bug Tracker reports
Le 31/10/2018 à 21:52, William A Rowe Jr a écrit : There are 715 reports tagged 2.0.0 through 2.3-HEAD of Status NEW or NEEDINFO with no Resolution. For these bugs I believe we should simply close them with a message that this is a mass-update, that the version is beyond EOL, and a request for reporters/observers to retest and reopen with the supported version number if they are still reproducible using a modern 2.4.x version. But I can't determine the best Status/Resolution code... suggestions? +1 IMHO, the best status would be CLOSED/WONTFIX. Maybe a new Keyword such as TooOldAndInactive to ease finding such mass-update? Or ask for a new status TOO_OLD (but I'm not sure it would really be that useful) There are 69 bugs of status REOPENED, and 20 of status ASSIGNED (?). These should likely be reviewed by hand and either ACCEPTED against 2.4-HEAD, tagged NEEDINFO with a request to re-review (after mass-cleanup of NEEDINFO above), or closed as above with an invitation to retest and reopen. +1, after by-hand review, as proposed. There are 255 bugs of Status NEW from 2.4.1-2.4.17, releases which are over three years old. For these, the best resolution is probably NEEDINFO. -1. Not sure NEEDINFO is fine for these ones. We should set NEEDINFO after by hand review, if we NEEDINFO. Or close it if invalid, or leave it as is if it looks right but no one has looked at it. The reporter has done his job. He has reported what he thinks is enough. WE should provide an answer or ask for more details. And there are 38 2.4.x NEEDINFO bugs, most of which can likely be closed for good as INVALID under a manual review. +1 if older than, let say, 1 year? The number is small, they could also be doubled check by hand. But is is likely, that it would end as INVALID because the analysis has already been done, and the reporter does not seem to be interested to answer. I'm thinking of generic comment which would read (2nd paragraph for 2.0-2.3.x only); """ Please help us to refine our list of open and current defects. This is a mass update of older Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. [...]. This is a mass update of old and inactive reports [...] As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. [...] a defect in httpd or a feature request [...] Your help in identifying only current defects in the httpd server software is greatly appreciated. """ Comments, suggestions and other feedback before we proceed to take a broad scythe to the stale reports? We should also forbid bug report against 2.2.x. CJ
