Using Heartbleed headers to share site status

The Heartbleed SSL vulnerability was announced on April 7, 2014. Its causes and fixes are well documented elsewhere. Unfortunately, there is no standard manner of communicating whether a site has been unaffected, compromised, or fixed. That has severe security implications for visitors who can't tell if - or when - they should be changing their password on a particular site.

This proposal is a method of informing users about a site's state. It adds an easily parseable HTTP header to responses so that clients (or sufficiently helpful user agents) may act appropriately.

Long-term uses

Heartbleed is one specific vulnerability affecting one specific software library. It is likely that another vulnerability of similar scope and importance will be discovered in the future. By standardizing a manner of communicating status updates to users today, the risk and uncertainty of future incidents are lessened.

Although the Heartbleed header is named after this high-profile vulnerability, it is intended as a long-term mechanism for communicating future customer-affecting incidents in an automated fashion.

Note

Some organizations may believe that admitting vulnerability reflects poorly on their security. This is not true. By some estimates, over one third of SSL-encrypted websites on the Internet were vulnerable to the Heartbleed bug. There is no blame to be avoided and no fingers to be pointed. The only responsible course of action is to notify users so that they may take actions to protect themselves, and such notifications have been well received and respected by the Internet community.

Implementation

In HTTP response headers

Heartbleed: status; see http://heartbleedheader.com

where status is one of:

NO
The site has never been susceptible to Heartbleed or experienced an attack that exposed customer credentials.
YES
The site is currently susceptible to a Heartbleed attack or other SSL-related vulnerability.
FIXED: <date>
The site was vulnerable but was fixed as of the ISO 8601 timestamp. The SSL keys must still be replaced, but no new attacks are possible against it.
REPLACED: <date>
The site's vulnerability was fixed and its SSL keypair was replaced as of the timestamp. If an attacker compromised the site's secret key, they may still be able to impersonate the site to visitors.
REKEYED: <date>
The site's vulnerability was fixed and its SSL keypair was replaced and its old SSL key was revoked as of the timestamp. Visitors with browsers which support the site's certificate authority's certificate revocation list may visit the site safely, even if an attacker possesses the old key. This is the ideal response to the vulnerability.
UPDATECREDS: <date> [url]
The site's operators identified and fixed a non-SSL related vulnerability as of the timestamp, and visitors should change their password for this site if it is older than that timestamp. An optional URL may be provided to explain the scope of the vulnerability, suggest other actions, and so on.

In the body of an HTML document

Supply the same information using standard meta tags:

<meta http-equiv="Heartbleed" content="value; see http://heartbleedheader.com">

Example configurations

These are only general examples. Every server is different and has its own requirements.

Apache on Ubuntu 13.10

As root:


# cd /etc/apache2/mods-enabled
# ln -s ../mods-available/headers.load
# cd ../sites-enabled
# vi mysite.conf
...
<VirtualHost *:443>
   Header add Heartbleed "REPLACED: 2014-04-08; see http://heartbleedheader.com"
</VirtualHost>
...
# service apache2 restart

nginx on Ubuntu 13.10

As root:


# cd /etc/nginx/sites-enabled
# vi mysite.conf
server {
    ...
    add_header Heartbleed "NO; see http://heartbleedheader.com";
    ...
}

Users

These products and services are known to use Heartbleed headers: