The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.

SSL Renegotiation

Owned by Scott Cantor
Last updated: Dec 07, 2012 by 01000113936@co.calstate.edu (Deactivated)Version comment

Late last year a flaw was revealed in the TLS/SSL protocol that affects "renegotiation", which is a process for changing the details of a handshake after having connected to a server. One case in which renegotiation comes into play is when a client certificate is presented, or asked for, after initially connecting without one. Either the client or server can ask for this.

Shibboleth does not explicitly require renegotiation, but it does commonly rely on TLS client authentication when an SP connects to an IdP to communicate using SOAP, commonly during attribute queries when SAML 1.1 is used, or for artifact resolution. Newer versions have the option to rely on message signing in place of TLS client authentication, but this is not the default, is not all that common, and wasn't well supported by the 1.3 release branch.

Even when TLS client authentication is used, renegotiation isn't necessarily involved; it only comes into play if the IdP web server is hosting the SOAP endpoint(s) on the same virtual host with non-SOAP endpoints, and the TLS client authentication option is based on a location or directory rather than configured for the entire virtual host. This was more common with old Apache+mod_ssl combinations, particularly Apache 1.3, which did not support SSLVerifyClient at the VirtualHost level.

Furthermore, as best we have been able to determine, the flaw in the protocol does not represent a security threat to the use of client authentication in Shibboleth, mainly because the use of the feature is generally restricted to a non-browser client (the SP) and the data returned is not visible to the attacker. The threat pertains more to environments in which submitting data using the client's certificate can have side effects.

Unfortunately, the fact that Shibboleth is not (apparently) vulnerable doesn't help when the underlying software is modified to break or block the use of renegotiation, and this has become the case when certain versions of OpenSSL and/or web server software are used. Even worse, the problem can manifest at either the SP or IdP, and may occur without warning if standard vendor-supplied patches are applied.

There is nothing the Shibboleth project team can do about this situation, but we are collecting information here to help with diagnosis and to suggest workarounds.

How to Tell if You're Affected

A failure to renegotiate may result in errors in the SSL-related logging of the IdP web server, but results in a libcurl-reported connection timeout error on the SP end (in the shibd.log). If timeouts start occuring for no reason, and you can successfully reach the affected web server from the SP machine, chances are this is the problem.

Note that given the relatively small number of IdPs that rely on renegotiation, it's quite likely that a given SP will see this problem only in specific cases (unless the majority of users come from an affected IdP), but an affected IdP may of course see widespread problems.

Breaking Updates

There are two main causes for this problem. At the SP end, the breaking change involves the use of an OpenSSL version newer than 0.9.8k, or an older version from a vendor that's been patched with upstream changes to correct this flaw. At the time of writing, most Linux vendors have shipped such updates, including Red Hat/CentOS and SUSE, as has Apple and the official Macport.

A good summary of the situation and the various patches from Red Hat can be found at http://kbase.redhat.com/faq/docs/DOC-20491

With the change from version 0.9.8l, renegotiation is blocked entirely. With version 0.9.8m, a new TLS extension is supported that re-enabled renegotiation if the server is also patched with support for the extension. The SP also now includes an option to re-enable "unsafe" renegotiation if version 0.9.8m or newer is used.

At the IdP end, there are more moving parts because it depends on the web server in use and possibly the OpenSSL version, if Apache+mod_ssl is involved. Newer versions of Tomcat and other Java web servers may include patches that block unsafe renegotiation, or include support for the extension or re-enabling the unsafe code. The latest Apache+mod_ssl patches disable unsafe renegotiation by default, but include a new SSLInsecureRenegotiation option to re-enable it. They also support the TLS extension that allows supporting versions of OpenSSL to work properly regardless.

Workarounds

The best advice we can give is to IdP deployers; do NOT rely on subdirectory or location-based client authentication configuration. Instead, use a dedicated virtual host (whether by address or port, typically 8443) and configure client authentication for the entire virtual host.

If you're using Apache 1.3 and cannot do this, please consider upgrading. Apache 1.3 is now officially EOL and is a dead product.

If you're an SP and are affected by this problem, there's not much you can do other than to downgrade to unpatched OpenSSL code or use a new enough OpenSSL version to allow for the workaround.

If no other work-around is available, an SP deployer may be able to re-establish connectivity by disabling TLS client authentication and enabling signing, if the IdP supports this option. This is achieved by creating a <RelyingParty> element for the IdP like so:

<RelyingParty Name="https://affected.idp.org/idp/shibboleth" authType="none" signing="back"/>

This hasn't been tested, and it's possible that the server simply supporting TLS client authentication may be enough to cause renegotiation, in which case nothing the SP does will make a difference.