EZproxy - POODLE security issues and other listserv discussion

[Hamparian,Don]

Hi all, it's been a busy week of announced security issues and listserv discussion. Instead of responding to the many individual messages in the listserv, I'm summarizing them here.

Poodle Security Issue (see http://googleonlinesecurity.blogspot.nl/2014/10/this-poodle-bites-exploiting-ssl-30.html) and CVE-2014-3566<http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3566>. This is a medium severity issue as scored by NIST.

We will release an updated V5.7 release that, by default, has SSL 3 turned off and will supply an option to turn it back on. Using SSL 3 is not recommended however there may be some institutions that have old browser versions and need it.

This will also be the behavior for the upcoming V6.0 release. In the V6.1 release, we will also make an improvement to the SSLCipherSuite command to make sure all OpenSSL-supported cipher options are usable by EZproxy. This change, coupled with the new SSL 3 switch, will provide fine-grained control of EZproxy's SSL configuration.

OpenSSL library Version

Also, in the updated V5.7 release and the upcoming V6.0 release we will build against OpenSSL 0.9.8zc. This update will resolve CVE 2014-3513 (Rated HIGH by OpenSSL) and CVE 2014-3567 (rated Medium by OpenSSL).

Also, OpenSSL announced end of support for OpenSSL version 0.9.8 on December 31 2015. We will build EZproxy V6 on OpenSSL V1 (the next release of OpenSSL) and have it available by July 2015.

The way we build EZproxy with OpenSSL (Why don't you dynamically link against OpenSSL?)

Today we statically link OpenSSL's binary library with EZproxy. We do this because this build method makes installation of EZproxy much easier for our EZproxy institutions. The vast majority of our institutions are not advanced systems administrators and by shipping EZProxy this way, we help simplify the institution's installation and maintenance process for EZproxy - the institution doesn't have to track and manage the OpenSSL version on their system.

We are going to further evaluate whether or not we should build EZproxy by dynamically linking OpenSSL, but we have no current plans to build EZproxy that way.

Security issue reported as CVE-2014-3660<https://access.redhat.com/security/cve/CVE-2014-3660> (libxml denial of service) - rated "Moderate"

EZproxy has a potential to be affected by this issue, however the access points are in not frequently used EZproxy facilities. We will make the recommended change that this CVE recommends in the V6.0 release of EZproxy.

Supply a 64 bit build of EZproxy

Newer Windows and Linux systems are 64 bit-based operating systems, which provide a much larger address space for programs like EZproxy. Very few EZproxy institutions are seeing this memory limit, however a few are starting to bump up against it.

In some cases, a 64 bit version of the same program (such as the 64 bit Chrome browser) will run slightly faster than the 32 bit equivalent. Both Linux and Windows have very good facilities for running 32 bit applications on 64 bit operating systems.

However the more significant issue for EZproxy is the memory limit. Because of this potential (and it's still pretty rare) issue, we are planning to provide 64 bit builds of EZproxy V6.x in the future.

Don Hamparian
Sr. Product Manager,
EZproxy and Identity Management
OCLC
***@oclc.org<mailto:***@oclc.org>
Voice 614-764-6017
Skype donhamp2


---
You are currently subscribed to ezproxy as: gee-***@m.gmane.org.
To unsubscribe, send request to ***@itec.suny.edu

[Andrew Anderson]

Don’t forget that 64-bit is not just for memory access, but also file access as well. We had to make adjustments to our EZproxy log file handling because we kept hitting the 32-bit 2GB log file size limitation inherent in the 32-bit builds.

This also has implications on EZproxy’s ability to proxy resources (read: streams) that are > 2GB in size, but thankfully those instances where we can hit that limit are somewhat rare.
--
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

Hi all, it’s been a busy week of announced security issues and listserv discussion. Instead of responding to the many individual messages in the listserv, I’m summarizing them here.
Poodle Security Issue (see http://googleonlinesecurity.blogspot.nl/2014/10/this-poodle-bites-exploiting-ssl-30.html) and CVE-2014-3566. This is a medium severity issue as scored by NIST.
We will release an updated V5.7 release that, by default, has SSL 3 turned off and will supply an option to turn it back on. Using SSL 3 is not recommended however there may be some institutions that have old browser versions and need it.
This will also be the behavior for the upcoming V6.0 release. In the V6.1 release, we will also make an improvement to the SSLCipherSuite command to make sure all OpenSSL-supported cipher options are usable by EZproxy. This change, coupled with the new SSL 3 switch, will provide fine-grained control of EZproxy’s SSL configuration.
OpenSSL library Version
Also, in the updated V5.7 release and the upcoming V6.0 release we will build against OpenSSL 0.9.8zc. This update will resolve CVE 2014-3513 (Rated HIGH by OpenSSL) and CVE 2014-3567 (rated Medium by OpenSSL).
Also, OpenSSL announced end of support for OpenSSL version 0.9.8 on December 31 2015. We will build EZproxy V6 on OpenSSL V1 (the next release of OpenSSL) and have it available by July 2015.
The way we build EZproxy with OpenSSL (Why don’t you dynamically link against OpenSSL?)
Today we statically link OpenSSL’s binary library with EZproxy. We do this because this build method makes installation of EZproxy much easier for our EZproxy institutions. The vast majority of our institutions are not advanced systems administrators and by shipping EZProxy this way, we help simplify the institution’s installation and maintenance process for EZproxy – the institution doesn’t have to track and manage the OpenSSL version on their system.
We are going to further evaluate whether or not we should build EZproxy by dynamically linking OpenSSL, but we have no current plans to build EZproxy that way.
Security issue reported as CVE-2014-3660 (libxml denial of service) – rated “Moderate”
EZproxy has a potential to be affected by this issue, however the access points are in not frequently used EZproxy facilities. We will make the recommended change that this CVE recommends in the V6.0 release of EZproxy.
Supply a 64 bit build of EZproxy
Newer Windows and Linux systems are 64 bit-based operating systems, which provide a much larger address space for programs like EZproxy. Very few EZproxy institutions are seeing this memory limit, however a few are starting to bump up against it.
In some cases, a 64 bit version of the same program (such as the 64 bit Chrome browser) will run slightly faster than the 32 bit equivalent. Both Linux and Windows have very good facilities for running 32 bit applications on 64 bit operating systems.
However the more significant issue for EZproxy is the memory limit. Because of this potential (and it’s still pretty rare) issue, we are planning to provide 64 bit builds of EZproxy V6.x in the future.
Don Hamparian
Sr. Product Manager,
EZproxy and Identity Management
OCLC
Voice 614-764-6017
Skype donhamp2

---
You are currently subscribed to ezproxy as: gee-***@m.gmane.org.
To unsubscribe, send request to ***@itec.suny.edu

[Boogie Shafer]

July 2015 seems a LONG WAY OFF given the pace of the openssl exploits...esp if the openssl library is bundled in, i would think that component could be updated more quickly



does "OpenSSL V1" mentioned for V6 mean 1.0.1 (which supports TLSv1.1 and TLSv1.2) or 1.0.0 (which lacks those current generation protocols)?




________________________________
From: Andrew Anderson <***@lirn.net>
Sent: Tuesday, October 21, 2014 13:50
To: EZProxy discussion list
Subject: Re: [ezproxy] EZproxy - POODLE security issues and other listserv discussion


Don’t forget that 64-bit is not just for memory access, but also file access as well. We had to make adjustments to our EZproxy log file handling because we kept hitting the 32-bit 2GB log file size limitation inherent in the 32-bit builds.

This also has implications on EZproxy’s ability to proxy resources (read: streams) that are > 2GB in size, but thankfully those instances where we can hit that limit are somewhat rare.

--
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

On Oct 21, 2014, at 12:36, Hamparian,Don <***@oclc.org<mailto:***@oclc.org>> wrote:

Hi all, it’s been a busy week of announced security issues and listserv discussion. Instead of responding to the many individual messages in the listserv, I’m summarizing them here.

Poodle Security Issue (see http://googleonlinesecurity.blogspot.nl/2014/10/this-poodle-bites-exploiting-ssl-30.html) and CVE-2014-3566<http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3566>. This is a medium severity issue as scored by NIST.

We will release an updated V5.7 release that, by default, has SSL 3 turned off and will supply an option to turn it back on. Using SSL 3 is not recommended however there may be some institutions that have old browser versions and need it.

This will also be the behavior for the upcoming V6.0 release. In the V6.1 release, we will also make an improvement to the SSLCipherSuite command to make sure all OpenSSL-supported cipher options are usable by EZproxy. This change, coupled with the new SSL 3 switch, will provide fine-grained control of EZproxy’s SSL configuration.

OpenSSL library Version

Also, in the updated V5.7 release and the upcoming V6.0 release we will build against OpenSSL 0.9.8zc. This update will resolve CVE 2014-3513 (Rated HIGH by OpenSSL) and CVE 2014-3567 (rated Medium by OpenSSL).

Also, OpenSSL announced end of support for OpenSSL version 0.9.8 on December 31 2015. We will build EZproxy V6 on OpenSSL V1 (the next release of OpenSSL) and have it available by July 2015.

The way we build EZproxy with OpenSSL (Why don’t you dynamically link against OpenSSL?)

Today we statically link OpenSSL’s binary library with EZproxy. We do this because this build method makes installation of EZproxy much easier for our EZproxy institutions. The vast majority of our institutions are not advanced systems administrators and by shipping EZProxy this way, we help simplify the institution’s installation and maintenance process for EZproxy – the institution doesn’t have to track and manage the OpenSSL version on their system.

We are going to further evaluate whether or not we should build EZproxy by dynamically linking OpenSSL, but we have no current plans to build EZproxy that way.

Security issue reported as CVE-2014-3660<https://access.redhat.com/security/cve/CVE-2014-3660> (libxml denial of service) – rated “Moderate”

EZproxy has a potential to be affected by this issue, however the access points are in not frequently used EZproxy facilities. We will make the recommended change that this CVE recommends in the V6.0 release of EZproxy.

Supply a 64 bit build of EZproxy

Newer Windows and Linux systems are 64 bit-based operating systems, which provide a much larger address space for programs like EZproxy. Very few EZproxy institutions are seeing this memory limit, however a few are starting to bump up against it.

In some cases, a 64 bit version of the same program (such as the 64 bit Chrome browser) will run slightly faster than the 32 bit equivalent. Both Linux and Windows have very good facilities for running 32 bit applications on 64 bit operating systems.

However the more significant issue for EZproxy is the memory limit. Because of this potential (and it’s still pretty rare) issue, we are planning to provide 64 bit builds of EZproxy V6.x in the future.

Don Hamparian
Sr. Product Manager,
EZproxy and Identity Management
OCLC
***@oclc.org<mailto:***@oclc.org>
Voice 614-764-6017
Skype donhamp2


You are currently subscribed to ezproxy as: ***@lirn.net<mailto:***@lirn.net>.
To unsubscribe, send request to ***@itec.suny.edu<mailto:***@itec.suny.edu>


You are currently subscribed to ezproxy as: ***@proquest.com.
To unsubscribe, send request to ***@itec.suny.edu

---
You are currently subscribed to ezproxy as: gee-***@m.gmane.org.
To unsubscribe, send request to ***@itec.suny.edu

[John Benedetto]

WOW! Are you that busy, or do you have a long period of time between rotating logs?

From: Andrew Anderson [mailto:***@lirn.net]
Sent: Tuesday, October 21, 2014 2:51 PM
To: EZProxy discussion list
Subject: Re: [ezproxy] EZproxy - POODLE security issues and other listserv discussion


Don't forget that 64-bit is not just for memory access, but also file access as well. We had to make adjustments to our EZproxy log file handling because we kept hitting the 32-bit 2GB log file size limitation inherent in the 32-bit builds.


---
You are currently subscribed to ezproxy as: gee-***@m.gmane.org.
To unsubscribe, send request to ***@itec.suny.edu

[Julien Savoie]

[Chris Manly]

Once upon a time, I think the "we're going to package it in a way that's the most reliable for non-technical users" approach was appropriate. However, I think that time has ended, for two reasons:

1) Folks who don't/can't handle it can host EZProxy with OCLC
2) The security landscape has changed rapidly in the past few years. Folks are finding serious flaws in core software like openssl, and where Higher Ed used to be a vector for compromise, we are now an active target.

--
Christopher Manly
Coordinator, Library Systems
Cornell University Library Information Technologies
***@cornell.edu
607-255-3344

From: Julien Savoie <***@usainteanne.ca<mailto:***@usainteanne.ca>>
Reply-To: EZProxy discussion list <***@ls.suny.edu<mailto:***@ls.suny.edu>>
Date: Tuesday, October 21, 2014 at 6:35 PM
To: EZProxy discussion list <***@ls.suny.edu<mailto:***@ls.suny.edu>>
Subject: Re: [ezproxy] EZproxy - POODLE security issues and other listserv discussion

On 21/10/14 01:36 PM, Hamparian,Don wrote:
Today we statically link OpenSSL's binary library with EZproxy. We do this because this build method makes installation of EZproxy much easier for our EZproxy institutions. The vast majority of our institutions are not advanced systems administrators and by shipping EZProxy this way, we help simplify the institution's installation and maintenance process for EZproxy - the institution doesn't have to track and manage the OpenSSL version on their system.
So they're too "not advanced" to patch their server, but you feel they're "advanced" enough to keep EZProxy updated?

$ sudo apt-get update && sudo apt-get upgrade
or
$ su -c 'yum update'

Versus reading the list, or routinely checking the website then pulling down the ezproxy.bin file and killing/restarting the daemon? Do you have any statistics on what percentage of ezproxy installs are running the latest available version?



You are currently subscribed to ezproxy as: ***@cornell.edu<mailto:***@cornell.edu>.
To unsubscribe, send request to ***@itec.suny.edu<mailto:***@itec.suny.edu>

---
You are currently subscribed to ezproxy as: gee-***@m.gmane.org.
To unsubscribe, send request to ***@itec.suny.edu

[Hamparian,Don]

Andrew, agree that this is a benefit of 64 bit too. We have seen this a few times in very active sites. We mitigated as I suspect you did by rotating log files daily.

From: Andrew Anderson [mailto:***@lirn.net]
Sent: Tuesday, October 21, 2014 4:51 PM
To: EZProxy discussion list
Subject: Re: [ezproxy] EZproxy - POODLE security issues and other listserv discussion


Don't forget that 64-bit is not just for memory access, but also file access as well. We had to make adjustments to our EZproxy log file handling because we kept hitting the 32-bit 2GB log file size limitation inherent in the 32-bit builds.

This also has implications on EZproxy's ability to proxy resources (read: streams) that are > 2GB in size, but thankfully those instances where we can hit that limit are somewhat rare.

--
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

On Oct 21, 2014, at 12:36, Hamparian,Don <***@oclc.org<mailto:***@oclc.org>> wrote:


Hi all, it's been a busy week of announced security issues and listserv discussion. Instead of responding to the many individual messages in the listserv, I'm summarizing them here.

Poodle Security Issue (see http://googleonlinesecurity.blogspot.nl/2014/10/this-poodle-bites-exploiting-ssl-30.html) and CVE-2014-3566<http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3566>. This is a medium severity issue as scored by NIST.

We will release an updated V5.7 release that, by default, has SSL 3 turned off and will supply an option to turn it back on. Using SSL 3 is not recommended however there may be some institutions that have old browser versions and need it.

This will also be the behavior for the upcoming V6.0 release. In the V6.1 release, we will also make an improvement to the SSLCipherSuite command to make sure all OpenSSL-supported cipher options are usable by EZproxy. This change, coupled with the new SSL 3 switch, will provide fine-grained control of EZproxy's SSL configuration.

OpenSSL library Version

Also, in the updated V5.7 release and the upcoming V6.0 release we will build against OpenSSL 0.9.8zc. This update will resolve CVE 2014-3513 (Rated HIGH by OpenSSL) and CVE 2014-3567 (rated Medium by OpenSSL).

Also, OpenSSL announced end of support for OpenSSL version 0.9.8 on December 31 2015. We will build EZproxy V6 on OpenSSL V1 (the next release of OpenSSL) and have it available by July 2015.

The way we build EZproxy with OpenSSL (Why don't you dynamically link against OpenSSL?)

Today we statically link OpenSSL's binary library with EZproxy. We do this because this build method makes installation of EZproxy much easier for our EZproxy institutions. The vast majority of our institutions are not advanced systems administrators and by shipping EZProxy this way, we help simplify the institution's installation and maintenance process for EZproxy - the institution doesn't have to track and manage the OpenSSL version on their system.

We are going to further evaluate whether or not we should build EZproxy by dynamically linking OpenSSL, but we have no current plans to build EZproxy that way.

Security issue reported as CVE-2014-3660<https://access.redhat.com/security/cve/CVE-2014-3660> (libxml denial of service) - rated "Moderate"

EZproxy has a potential to be affected by this issue, however the access points are in not frequently used EZproxy facilities. We will make the recommended change that this CVE recommends in the V6.0 release of EZproxy.

Supply a 64 bit build of EZproxy

Newer Windows and Linux systems are 64 bit-based operating systems, which provide a much larger address space for programs like EZproxy. Very few EZproxy institutions are seeing this memory limit, however a few are starting to bump up against it.

In some cases, a 64 bit version of the same program (such as the 64 bit Chrome browser) will run slightly faster than the 32 bit equivalent. Both Linux and Windows have very good facilities for running 32 bit applications on 64 bit operating systems.

However the more significant issue for EZproxy is the memory limit. Because of this potential (and it's still pretty rare) issue, we are planning to provide 64 bit builds of EZproxy V6.x in the future.

Don Hamparian
Sr. Product Manager,
EZproxy and Identity Management
OCLC
***@oclc.org<mailto:***@oclc.org>
Voice 614-764-6017
Skype donhamp2


You are currently subscribed to ezproxy as: ***@lirn.net<mailto:***@lirn.net>.
To unsubscribe, send request to ***@itec.suny.edu<mailto:***@itec.suny.edu>


You are currently subscribed to ezproxy as: ***@oclc.org<mailto:***@oclc.org>.
To unsubscribe, send request to ***@itec.suny.edu<mailto:***@itec.suny.edu>

---
You are currently subscribed to ezproxy as: gee-***@m.gmane.org.
To unsubscribe, send request to ***@itec.suny.edu

[Hamparian,Don]

Let me be clear, I said "by July 2015" not "on July 1 2015." We will build against whatever the latest OpenSSL is at the point we have made the changes to support OpenSSL V1.x.

Thanks

From: Boogie Shafer [mailto:***@proquest.com]
Sent: Tuesday, October 21, 2014 4:58 PM
To: EZProxy discussion list
Subject: Re: [ezproxy] EZproxy - POODLE security issues and other listserv discussion




July 2015 seems a LONG WAY OFF given the pace of the openssl exploits...esp if the openssl library is bundled in, i would think that component could be updated more quickly





does "OpenSSL V1" mentioned for V6 mean 1.0.1 (which supports TLSv1.1 and TLSv1.2) or 1.0.0 (which lacks those current generation protocols)?







________________________________
From: Andrew Anderson <***@lirn.net<mailto:***@lirn.net>>
Sent: Tuesday, October 21, 2014 13:50
To: EZProxy discussion list
Subject: Re: [ezproxy] EZproxy - POODLE security issues and other listserv discussion


Don't forget that 64-bit is not just for memory access, but also file access as well. We had to make adjustments to our EZproxy log file handling because we kept hitting the 32-bit 2GB log file size limitation inherent in the 32-bit builds.

This also has implications on EZproxy's ability to proxy resources (read: streams) that are > 2GB in size, but thankfully those instances where we can hit that limit are somewhat rare.

--
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

On Oct 21, 2014, at 12:36, Hamparian,Don <***@oclc.org<mailto:***@oclc.org>> wrote:


Hi all, it's been a busy week of announced security issues and listserv discussion. Instead of responding to the many individual messages in the listserv, I'm summarizing them here.

Poodle Security Issue (see http://googleonlinesecurity.blogspot.nl/2014/10/this-poodle-bites-exploiting-ssl-30.html) and CVE-2014-3566<http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3566>. This is a medium severity issue as scored by NIST.

We will release an updated V5.7 release that, by default, has SSL 3 turned off and will supply an option to turn it back on. Using SSL 3 is not recommended however there may be some institutions that have old browser versions and need it.

This will also be the behavior for the upcoming V6.0 release. In the V6.1 release, we will also make an improvement to the SSLCipherSuite command to make sure all OpenSSL-supported cipher options are usable by EZproxy. This change, coupled with the new SSL 3 switch, will provide fine-grained control of EZproxy's SSL configuration.

OpenSSL library Version

Also, in the updated V5.7 release and the upcoming V6.0 release we will build against OpenSSL 0.9.8zc. This update will resolve CVE 2014-3513 (Rated HIGH by OpenSSL) and CVE 2014-3567 (rated Medium by OpenSSL).

Also, OpenSSL announced end of support for OpenSSL version 0.9.8 on December 31 2015. We will build EZproxy V6 on OpenSSL V1 (the next release of OpenSSL) and have it available by July 2015.

The way we build EZproxy with OpenSSL (Why don't you dynamically link against OpenSSL?)

Today we statically link OpenSSL's binary library with EZproxy. We do this because this build method makes installation of EZproxy much easier for our EZproxy institutions. The vast majority of our institutions are not advanced systems administrators and by shipping EZProxy this way, we help simplify the institution's installation and maintenance process for EZproxy - the institution doesn't have to track and manage the OpenSSL version on their system.

We are going to further evaluate whether or not we should build EZproxy by dynamically linking OpenSSL, but we have no current plans to build EZproxy that way.

Security issue reported as CVE-2014-3660<https://access.redhat.com/security/cve/CVE-2014-3660> (libxml denial of service) - rated "Moderate"

EZproxy has a potential to be affected by this issue, however the access points are in not frequently used EZproxy facilities. We will make the recommended change that this CVE recommends in the V6.0 release of EZproxy.

Supply a 64 bit build of EZproxy

Newer Windows and Linux systems are 64 bit-based operating systems, which provide a much larger address space for programs like EZproxy. Very few EZproxy institutions are seeing this memory limit, however a few are starting to bump up against it.

In some cases, a 64 bit version of the same program (such as the 64 bit Chrome browser) will run slightly faster than the 32 bit equivalent. Both Linux and Windows have very good facilities for running 32 bit applications on 64 bit operating systems.

However the more significant issue for EZproxy is the memory limit. Because of this potential (and it's still pretty rare) issue, we are planning to provide 64 bit builds of EZproxy V6.x in the future.

Don Hamparian
Sr. Product Manager,
EZproxy and Identity Management
OCLC
***@oclc.org<mailto:***@oclc.org>
Voice 614-764-6017
Skype donhamp2


You are currently subscribed to ezproxy as: ***@lirn.net<mailto:***@lirn.net>.
To unsubscribe, send request to ***@itec.suny.edu<mailto:***@itec.suny.edu>


You are currently subscribed to ezproxy as: ***@proquest.com<mailto:***@proquest.com>.
To unsubscribe, send request to ***@itec.suny.edu<mailto:***@itec.suny.edu>

You are currently subscribed to ezproxy as: ***@oclc.org<mailto:***@oclc.org>.
To unsubscribe, send request to ***@itec.suny.edu<mailto:***@itec.suny.edu>

---
You are currently subscribed to ezproxy as: gee-***@m.gmane.org.
To unsubscribe, send request to ***@itec.suny.edu

[Andrew Anderson]

Both of you make good points, and based on the posts made to the list, I suspect what you’ll find is that EZproxy gets installed at a location, setup, and promptly forgotten about until something stops working.

Also consider that when EZproxy was first written, remote access using telnet and rsh were in common use. I think these days you will be hard pressed to find any Linux distribution that does not install OpenSSH by default, thus ensuring that OpenSSL is available on the system for general use. On Windows platforms, using SChannel is the native equivalent there, so instead of looking to re-based to OpenSSL 1.x, switching to using the native platform’s SSL support would make a lot of sense.

Another option for OCLC to evaluate is using NSS instead of OpenSSL. In addition to being FIPS 140 certified at security levels 1 and 2, that library has an OpenSSL compatibility layer to make porting code to it simpler. I knew some of the people that worked full-time on that project, and they were working hard to ensure that there were as few barriers to adoption as possible to encourage people to migrate.
--
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

Post by Chris Manly
1) Folks who don't/can't handle it can host EZProxy with OCLC
2) The security landscape has changed rapidly in the past few years. Folks are finding serious flaws in core software like openssl, and where Higher Ed used to be a vector for compromise, we are now an active target.
--
Christopher Manly
Coordinator, Library Systems
Cornell University Library Information Technologies
607-255-3344
Date: Tuesday, October 21, 2014 at 6:35 PM
Subject: Re: [ezproxy] EZproxy - POODLE security issues and other listserv discussion

Post by Chris Manly

Today we statically link OpenSSL’s binary library with EZproxy. We do this because this build method makes installation of EZproxy much easier for our EZproxy institutions. The vast majority of our institutions are not advanced systems administrators and by shipping EZProxy this way, we help simplify the institution’s installation and maintenance process for EZproxy – the institution doesn’t have to track and manage the OpenSSL version on their system.

So they're too "not advanced" to patch their server, but you feel they're "advanced" enough to keep EZProxy updated?
$ sudo apt-get update && sudo apt-get upgrade
or
$ su -c 'yum update'
Versus reading the list, or routinely checking the website then pulling down the ezproxy.bin file and killing/restarting the daemon? Do you have any statistics on what percentage of ezproxy installs are running the latest available version?

---
You are currently subscribed to ezproxy as: gee-***@m.gmane.org.
To unsubscribe, send request to ***@itec.suny.edu