This wiki page is a work in progress and will be updated as new information is received and processed.
The Heartbleed Bug
A major new threat is sweeping the Internet. The Heartbleed Bug, announced publicly on April 7, 2014, is a serious vulnerability that affects certain versions of OpenSSL in circulation since 2012.
The following InCommon servers were not running a vulnerable version of OpenSSL and therefore were not affected by this bug:
- Federation Manager (service1.internet2.edu)
- Metadata Services (wayf.incommonfederation.org, md.incommon.org)
- Discovery Service (wayf.incommonfederation.org)
- Error Handling Service (ds.incommon.org)
The following InCommon server, which serves a single HTML resource, was found to be running a vulnerable version of OpenSSL:
- ops.incommon.org
The above server was patched, its TLS certificate was revoked, and a new TLS key and certificate were installed. This restored the integrity of the HTML resource (i.e., the fingerprints of the metadata signing certificate).
Recommendations for Deployers
If your SAML deployment relies on an affected version of OpenSSL, it is recommended that you take the following actions to mitigate the vulnerability:
- Patch the affected version of OpenSSL
- Follow the OS vendor's instructions to upgrade OpenSSL to the latest version
- Revoke your browser-facing TLS certificate
- Configure the system with a new trusted TLS key and certificate
- Revoke your SAML certificate in metadata
- Migrate a new certificate into metadata
When all but the final step above have been completed, follow these additional steps to migrate a new certificate into metadata:
- Read the X.509 Certificates in Metadata wiki page
- Use a long-lived, self-signed certificate
- IdP operators: Read the IdP Key Handling wiki page (SP owners might also benefit from reading this page)
- Handle the private IdP signing key securely!
- Read the Certificate Migration wiki page and its child pages
- Unless there is evidence that your IdP signing key has been compromised, migrate a new certificate into metadata, do not simply replace the old certificate (which will adversely affect interoperability).
- Assuming your SP partners follow InCommon recommendations with respect to Metadata Consumption, wait at least 24 hours for newly updated metadata to propagate throughout the Federation.
Note Well!
To the extent that you believe your system is vulnerable to The Heartbleed Bug, we provide the above noted guidance. Due to the unique nature of each affected system, you are of course the best source for determining solutions that meet the needs of a given system.
To ensure that you are receiving metadata updates from partners in a timely manner, review the metadata refresh process of each of your SAML deployments regardless of whether or not it is vulnerable:
- Is your software pointing to the correct metadata aggregate? See: Metadata Aggregates
- Have you installed the new metadata signing certificate? See: Metadata Signing Certificate
- Is your metadata refresh process optimally configured? See: Metadata Client Software
If you recently completed the widely publicized Metadata Migration Process, the above issues will have been already addressed.
Implementation-specific Information
If you deploy the Shibboleth SP on Windows, versions 2.5.0 (or later), consult the Shibboleth Security Advisory issued on 9 April 2014.
If you are using simpleSAMLphp, we recommend reading the entire thread entitled "heartbleed and SimpleSAMLphp" on the simpleSAMLphp mailing list.
Lessons Learned
For further discussion:
- The security and convenience of multilateral federation
- The agility of a metadata-based trust model
- The importance of secure, automated metadata refresh
- Is there value in defining separate keys for back-channel TLS?
Resources
- The Heartbleed Bug
- For more information, contact: admin@incommon.org