Andrew Anderson
2014-10-16 18:23:44 UTC
Today, there are additional issues in OpenSSL that need to be addressed as well:
https://access.redhat.com/security/cve/CVE-2014-3513
https://access.redhat.com/security/cve/CVE-2014-3567
I have updates installed or workarounds configured for both of these issues on my infrastructure now … except for EZproxy. There is no excuse for OCLC to be caught off-guard on these updates, as I know from firsthand past experience the level of coordination that exists between major open source projects and vendors on issues like this. OCLC should be an active participant in that coordination and have a release ready to go when the CVE is released.
Returning to the thread, the Apache API has not changed dramatically in a while now, so the 2.2/2.4 differences should be down to a small set of compile-time flags to manage a few differences in the internal Apache data structures for the different Apache releases. I know that with the Apache modules distributed with the OS, the only one that I see regularly updated with Apache is mod_ssl, but that is a different case. All of the other modules (mod_perl, mod_php, mod_wsgi, etc) happily continue running post update, so I do not see this as an issue that would block OCLC from going down the “mod_ezproxy” path.
With my sysadmin hat on, I would _much_ rather deal with a specialized Apache module than a huge monolithic binary with only-OCLC-knows-for-sure what versions of static library code compiled into it, no SELinux protection, etc.
Working within the OS framework will allow you to take advantage of several layers of security with no additional effort, makes your sysadmins happier, because they are working within a fully documented and well understood framework, not having to carry forward a legacy 32-bit runtime just for one application (how many “32-bit exploits on 64-bit cpus” do you remember seeing over the years?), and dealing with out-of-the box standard features for startup, shutdown, monitoring, management, log rotation, etc.
--
Andrew Anderson, Director of Development, Library and Information Resources Network, Inc.
http://www.lirn.net/ | http://www.twitter.com/LIRNnotes | http://www.facebook.com/LIRNnotes
You are currently subscribed to ezproxy as: gee-***@m.gmane.org.
To unsubscribe, send request to ***@itec.suny.edu
https://access.redhat.com/security/cve/CVE-2014-3513
https://access.redhat.com/security/cve/CVE-2014-3567
I have updates installed or workarounds configured for both of these issues on my infrastructure now … except for EZproxy. There is no excuse for OCLC to be caught off-guard on these updates, as I know from firsthand past experience the level of coordination that exists between major open source projects and vendors on issues like this. OCLC should be an active participant in that coordination and have a release ready to go when the CVE is released.
Returning to the thread, the Apache API has not changed dramatically in a while now, so the 2.2/2.4 differences should be down to a small set of compile-time flags to manage a few differences in the internal Apache data structures for the different Apache releases. I know that with the Apache modules distributed with the OS, the only one that I see regularly updated with Apache is mod_ssl, but that is a different case. All of the other modules (mod_perl, mod_php, mod_wsgi, etc) happily continue running post update, so I do not see this as an issue that would block OCLC from going down the “mod_ezproxy” path.
With my sysadmin hat on, I would _much_ rather deal with a specialized Apache module than a huge monolithic binary with only-OCLC-knows-for-sure what versions of static library code compiled into it, no SELinux protection, etc.
Working within the OS framework will allow you to take advantage of several layers of security with no additional effort, makes your sysadmins happier, because they are working within a fully documented and well understood framework, not having to carry forward a legacy 32-bit runtime just for one application (how many “32-bit exploits on 64-bit cpus” do you remember seeing over the years?), and dealing with out-of-the box standard features for startup, shutdown, monitoring, management, log rotation, etc.
--
Andrew Anderson, Director of Development, Library and Information Resources Network, Inc.
http://www.lirn.net/ | http://www.twitter.com/LIRNnotes | http://www.facebook.com/LIRNnotes
Not sure because then they would need to maintain different versions of mod_ezproxy for Apache 2.2, 2.4, etc. and sysadmins would also need to update Apache on a regular basis with all the trouble it can cause. Updating EZproxy is straightforward, you just change a binary.
Sébastien
________________________________________
Date d'envoi : 16 octobre 2014 11:02
À : EZProxy discussion list
Objet : Re: [ezproxy] SSL v3 support / poodle
ezproxy by a vendor specific demand/issue in 2006.
facing services without an IPv6 address associated.
understand they might be nervous about. I would settle for being able
to use my own OpenSSL library. I do rather like the idea of a
mod_ezproxy module. It might actually make things easier on OCLC's side
with a smaller codebase to manage.
---
---
---Sébastien
________________________________________
Date d'envoi : 16 octobre 2014 11:02
À : EZProxy discussion list
Objet : Re: [ezproxy] SSL v3 support / poodle
The worst kept secret of rewriting proxies is that as of Apache 2.4, the only thing that really separates EZproxy from Apache is the specialized vendor integration components and the configuration file format (which can be viewed as a strength in some cases and a weakness in others).
Depending on your vendor mix, it is possible today to use Apache instead of EZproxy as your rewriting proxy server.
I actually recall being forced to switch from apache mod_proxy toDepending on your vendor mix, it is possible today to use Apache instead of EZproxy as your rewriting proxy server.
ezproxy by a vendor specific demand/issue in 2006.
Just imagine: a mature and robust dual-stack (IPv4/IPv6) platform, integrated caching, just about any 3rd party authentication integration you could want, the ability to integrate other applications into the same server (CMS, etc), better static file serving, a security layer option, a server that does not shutdown from mysterious threading timeouts, complete documentation, the list goes on and on.
IPv6 in ezproxy would be nice. Ezproxy is one of our few externallyfacing services without an IPv6 address associated.
Should OCLC decide to open source EZproxy, I know that myself and others on this list would dive into it with abandon to merge the best of Apache and the best of EZproxy, and the result would be a tremendous leap forward.
Or conversely merge the vendor specific bits into apache, which I canunderstand they might be nervous about. I would settle for being able
to use my own OpenSSL library. I do rather like the idea of a
mod_ezproxy module. It might actually make things easier on OCLC's side
with a smaller codebase to manage.
---
---
You are currently subscribed to ezproxy as: gee-***@m.gmane.org.
To unsubscribe, send request to ***@itec.suny.edu