Known issues

Last updated
Save as PDF

This page lists known issues in EZproxy. Availability dates are subject to change.

Please see the OCLC System Status Dashboard for active issues.

Current Issues

Installation & Configuration

Issue	Details
EZproxy on Windows unable to support LDAP over IPv6 Version Affected: V6.0 and later	EZproxy v6.0 added support for IPv6, but did not add this support to LDAP. EZproxy V6.1.6 made LDAP aware of IPv6 addresses, but the library support was not enabled correctly to support this, causing failures for sites that have both IPv4 and IPv6 addresses for their LDAP servers. At this time LDAP support will be limited to IPv4 on Windows, but IPv6 will be supported on other platforms.

Issue

Details

EZproxy on Windows unable to support LDAP over IPv6

Version Affected: V6.0 and later

EZproxy v6.0 added support for IPv6, but did not add this support to LDAP. EZproxy V6.1.6 made LDAP aware of IPv6 addresses, but the library support was not enabled correctly to support this, causing failures for sites that have both IPv4 and IPv6 addresses for their LDAP servers.

At this time LDAP support will be limited to IPv4 on Windows, but IPv6 will be supported on other platforms.

Security

Issue Details

Issue	Details
FREAK Vulnerability	EZproxy V5.7.44 and V6.0.7 are NOT vulnerable to the FREAK security issue IF you have the following settings in your config.txt: `Option DisableSSL40bit Option DisableSSL56bit Option DisableSSLv2` Add the following directives to your config.txt to protect against the FREAK vulnerability: `Option DisableSSL40bit Option DisableSSL56bit Option DisableSSLv2`

FREAK Vulnerability

EZproxy V5.7.44 and V6.0.7 are NOT vulnerable to the FREAK security issue IF you have the following settings in your config.txt:

Option DisableSSL40bit Option DisableSSL56bit Option DisableSSLv2

Add the following directives to your config.txt to protect against the FREAK vulnerability:

Option DisableSSL40bit Option DisableSSL56bit Option DisableSSLv2

Build issues

Issue	Details
Support for IPv6 Addresses via the EZproxy Location directive Version affected: V6.0	EZproxy 6.0 does not support use of the Location directive to look up IPv6 addresses. We have not yet extended our support to the MaxMind V6 GeoLite database (GeoLiteCityv6). Fix Date: TBD A future version of EZproxy will incorporate new compatibility with IPv6 address lookup.
Using IPv4 addresses in IPv6 notation Version affected: V6.0	Do not use IPv4 addresses in IPv6 notation format to determine whether or not to make IPv6 network calls. For example, the IPv4 address 127.0.0.1 will not be treated equivalently to the IPv6 0:0:0:0:0:ffff:7f00:1 address. This is the designed behavior, and no remediation is planned
Dual Stack (IPv6/IPv4) cannot run when EZproxy is set to ProxyByPort Version affected: V6.0	In order to provide support for IPv6 ProxyByPort, you must duplicate the database stanzas using IPv6 syntax. This is the desired behavior, and no remediation is planned
The way we build EZproxy with OpenSSL Version affected: V6.0 and earlier	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 institution doesn’t have to track and manage the OpenSSL version on their system. We will further evaluate whether or not we should build EZproxy by dynamically linking OpenSSL, but we have no current plans to build EZproxy that way.
A 64 bit build of EZproxy Version affected: V6.0 and earlier	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. Fix Date: TBD Because of the potential memory limit issues (and it’s still pretty rare), we are planning to provide 64 bit builds of EZproxy V6.x in the future.

Issue

Details

Support for IPv6 Addresses via the EZproxy Location directive

Version affected: V6.0

EZproxy 6.0 does not support use of the Location directive to look up IPv6 addresses. We have not yet extended our support to the MaxMind V6 GeoLite database (GeoLiteCityv6).

Fix Date: TBD

A future version of EZproxy will incorporate new compatibility with IPv6 address lookup.

Using IPv4 addresses in IPv6 notation

Version affected: V6.0

Do not use IPv4 addresses in IPv6 notation format to determine whether or not to make IPv6 network calls. For example, the IPv4 address 127.0.0.1 will not be treated equivalently to the IPv6 0:0:0:0:0:ffff:7f00:1 address.

This is the designed behavior, and no remediation is planned

Dual Stack (IPv6/IPv4) cannot run when EZproxy is set to ProxyByPort

Version affected: V6.0

In order to provide support for IPv6 ProxyByPort, you must duplicate the database stanzas using IPv6 syntax.

This is the desired behavior, and no remediation is planned

The way we build EZproxy with OpenSSL

Version affected: V6.0 and earlier

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 institution doesn’t have to track and manage the OpenSSL version on their system.

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

A 64 bit build of EZproxy

Version affected: V6.0 and earlier

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.

Fix Date: TBD

Because of the potential memory limit issues (and it’s still pretty rare), we are planning to provide 64 bit builds of EZproxy V6.x in the future.

Fixed Issues

Fixed issues - Table

Installation & Configuration

Issue Fix date

Issue	Fix date
EZproxy security vulnerability for EZproxy versions 5.4 through 6.2.2 for customers using SAML-based authentication, such as Shibboleth, ADFS, Azure, or Okta. In rare cases, this vulnerability can result in unauthorized users obtaining a logged-in session on the EZproxy server. This error will be fixed in EZproxy 6.3, which is scheduled to be released in November 2017. In the meantime, the following hot fix is available. Immediately after each ::Shibboleth directive in user.txt, add “Group NULL”. For example: `::Shibboleth Group NULL IDP20 https://idp.institution.edu/idp/shibboleth /Shibboleth` If your authentication configuration is more complex than the above, or you have any concerns about adding this line to user.txt, please don’t hesitate to contact OCLC Support.	November 2017; V6.3 Actions required: Stand-alone EZproxy customers using SAML-based authentication: add the “Group NULL” directive to user.txt as soon as possible, and restart your EZproxy server. This directive will not impact properly authenticated users from being assigned to the correct Group. Hosted EZproxy customers using SAML-based authentication: no action is required. OCLC Support has already made this change for all hosted sites using SAML-based authentication, including self-service sites. EZproxy customers NOT using SAML-based authentication: no action is required.
Incorrect WSKey Expiration Recorded in Messages Log Version Affected: V6.0 For institutions that have upgraded to EZproxy V6.0 and installed a new WSKey, the EZproxy messages log records a message stating that the current key will expire 3 months from the date it was first installed.	September 2015; V6.1.6 EZproxy V6.1.6 introduced new WSKey alerts and handling. Please upgrade to V6.1.6 or later for more accurate WSKey expiration messages. For more details, see WSKey Validation and Messages.
Support for the EZproxy Location directive and IPv4 Lookup with GeoLiteCity data Version affected: V6.0 EZproxy 6.0 introduced a problem with the Location directive for geo-ip lookup using IPv4 addresses. Lookups using IPv4 addresses to the MaxMind GeoLite database do not return correct results.	May 2015; V6.0.8 EZproxy V6.0.8 will reinstate compatibility with MaxMind and GeoLiteCity data with IPv4 address lookup.
Sessions that exceed their session lifetime (as defined by MaxLifetime) are not being correctly removed from EZproxy's session table. Version affected: V6.0 Expired sessions are not being deleted from EZproxy's session table and eventually EZproxy exceeds the MaxSessions value and no more sessions can be created.	May 2015; V6.0.8 EZproxy V6.0.8 will reinstate previous behavior of this functionality.

EZproxy security vulnerability for EZproxy versions 5.4 through 6.2.2 for customers using SAML-based authentication, such as Shibboleth, ADFS, Azure, or Okta.

In rare cases, this vulnerability can result in unauthorized users obtaining a logged-in session on the EZproxy server.

This error will be fixed in EZproxy 6.3, which is scheduled to be released in November 2017. In the meantime, the following hot fix is available.

Immediately after each ::Shibboleth directive in user.txt, add “Group NULL”. For example:

::Shibboleth Group NULL IDP20 https://idp.institution.edu/idp/shibboleth /Shibboleth

If your authentication configuration is more complex than the above, or you have any concerns about adding this line to user.txt, please don’t hesitate to contact OCLC Support.

November 2017; V6.3

Actions required:

Stand-alone EZproxy customers using SAML-based authentication: add the “Group NULL” directive to user.txt as soon as possible, and restart your EZproxy server. This directive will not impact properly authenticated users from being assigned to the correct Group.

Hosted EZproxy customers using SAML-based authentication: no action is required. OCLC Support has already made this change for all hosted sites using SAML-based authentication, including self-service sites.

EZproxy customers NOT using SAML-based authentication: no action is required.

Incorrect WSKey Expiration Recorded in Messages Log

Version Affected: V6.0

For institutions that have upgraded to EZproxy V6.0 and installed a new WSKey, the EZproxy messages log records a message stating that the current key will expire 3 months from the date it was first installed.

September 2015; V6.1.6

EZproxy V6.1.6 introduced new WSKey alerts and handling. Please upgrade to V6.1.6 or later for more accurate WSKey expiration messages.

For more details, see WSKey Validation and Messages.

Support for the EZproxy Location directive and IPv4 Lookup with GeoLiteCity data

Version affected: V6.0

EZproxy 6.0 introduced a problem with the Location directive for geo-ip lookup using IPv4 addresses. Lookups using IPv4 addresses to the MaxMind GeoLite database do not return correct results.

May 2015; V6.0.8

EZproxy V6.0.8 will reinstate compatibility with MaxMind and GeoLiteCity data with IPv4 address lookup.

Sessions that exceed their session lifetime (as defined by MaxLifetime) are not being correctly removed from EZproxy's session table.

Version affected: V6.0

Expired sessions are not being deleted from EZproxy's session table and eventually EZproxy exceeds the MaxSessions value and no more sessions can be created.

May 2015; V6.0.8

EZproxy V6.0.8 will reinstate previous behavior of this functionality.

Security

Issue	Fix date
Poodle Security Issue-Medium (as rated by NIST) See: http://googleonlinesecurity.blogspot.nl/2014/10/this-poodle-bites-exploiting-ssl-30.html CVE-2014-3566	Improvements Date: January 2015, V6.0 EZproxy V6.0 also has SSL3 turned off by default. In the V6.0 release, an improvement was made to the Option SSLCipherSuite command to make sure all OpenSSL-supported cipher options are usable by EZproxy. This change, coupled with the new SSL 3 switch, provides fine-grained control of EZproxy’s SSL configuration. Fix Date: November 2014, V5.7.44 By default, EZproxy V5.7.44 has SSL 3 turned off by default, but you have the option to turn it back on. Using SSL 3 is not recommended, but there may be some institutions that have old browser versions that require it.
Open SSL Security Issue CVE 2014-3513-High CVE 2014-2567-Medium (as rated by OpenSSL) See: CVE 2014-3513 CVE 2014-3567	November 2014, V5.7.44 The V5.7.44 and V6.0 releases were built against OpenSSL 0.9.8zc. Also, OpenSSL announced end of support for OpenSSL version 0.9.8 on December 31 2015. EZproxy V6.1 will be buit on OpenSSL V1.

Issue

Fix date

Poodle Security Issue-Medium
(as rated by NIST)

See:

Improvements Date: January 2015, V6.0

EZproxy V6.0 also has SSL3 turned off by default. In the V6.0 release, an improvement was made to the Option SSLCipherSuite command to make sure all OpenSSL-supported cipher options are usable by EZproxy. This change, coupled with the new SSL 3 switch, provides fine-grained control of EZproxy’s SSL configuration.

Fix Date: November 2014, V5.7.44

By default, EZproxy V5.7.44 has SSL 3 turned off by default, but you have the option to turn it back on. Using SSL 3 is not recommended, but there may be some institutions that have old browser versions that require it.

Open SSL Security Issue

CVE 2014-3513-High
CVE 2014-2567-Medium
(as rated by OpenSSL)

See:

November 2014, V5.7.44

The V5.7.44 and V6.0 releases were built against OpenSSL 0.9.8zc. Also, OpenSSL announced end of support for OpenSSL version 0.9.8 on December 31 2015.

EZproxy V6.1 will be buit on OpenSSL V1.