Brian Rue and Cory Virok

Heartbleed Bug Response

Updated 4/9 7:30pm

What is Heartbleed?

CVE-2014-0346, known as “Heartbleed”, is a bug in OpenSSL v1.0.1 through 1.0.1f that allows a remote attacker to access private memory on the target server. It has existed for almost 2 years. More info can be found here:

With this vulnerability, an attacker can:

  • Get your private key for your domain’s ssl cert
  • Decrypt all current and past SSL traffic to/from all affected machines

If this sounds bad, it is. Most sites on the Internet are affected.

Are you affected?

Probably. If your web server or load balancer is running on linux and you’ve updated your packages anytime in the last 2 years, you are more-than-likely affected.

To check your OpenSSL version, run openssl version -a

Check out to test your servers for the vulnerability.

How We Responded

We learned of CVE-2014-0346 at around 4:50pm on 4/7 and immediately began our response. We completed the most important fix (patching OpenSSL) within about an hour, and have been working over the past 24 hours on related issues.

Here is a timeline of what we’ve done since the vulnerability was announced:

  • 4/7 - 3:01pm - Ubuntu Security Announcements email

    Subscribe to this list here

  • 4/7 - 4:50pm - Began updating our load balancers with the fix. All servers patched by 6pm.

    We’re running nginx on Ubuntu 12.04. Updating is as simple as:

    apt-get update
    apt-get upgrade
    openssl version -a # should show that it was built on April 7, 2014
    service nginx restart

    The above didn’t work for us on the first try because our servers were talking to a mirror that hadn’t updated to the latest packages (after all, they were only a couple hours old). Changing the domain in each line in /etc/apt/sources.list to and then running apt-get update again solved this.

  • 4/7 - 11pm - and SSL certs were rekeyed

    We use DigiCert for our SSL certs. The process was quick and easy.

  • 4/7 - 11:10pm - Previous and SSL certs revoked

    In order to prevent a possible man-in-the-middle attack we had Digicert revoke our old certs.

  • 4/7 - 11:30pm - and rekey requested

    We still support our old domain, which use NetworkSolutions SSL certs

  • 4/8 - 11:50am - All cookies were invalidated, forcing users to re-auth

    Since an attacker could have accessed our customers’ cookies, we changed the secret key that we use to encrypt cookies. This invalidated all logged-in users’ sessions.

  • 4/8 - 12:30pm - 2:25pm - All third-party tokens and keys were regenerated and deployed

    We use services like Stripe, Mailgun, Heroku - All required new keys to be generated.

  • 4/8 - 3:30pm - and certs were rekeyed and deployed

  • 4/8 - 5:30pm - Published this blog post and added in-app notifications to change passwords and cycle access tokens

Update 4/9

Thanks to this post on security.stackexchange, we additionally patched our application and compute servers (everything that can make outgoing HTTPS requests). This was started at 3:45pm and completed at 4:45pm. The attack surface here is much lower, as it requires creating a Rollbar account and setting up a webhook that points to the attacker’s malicious server. We audited our logs and confirmed that there has been no such suspicious activity.

  • Change your password
  • Cycle any access tokens you have used (create and start using a new one, then disable or delete the old one).
    • For projects, go to the project dashboard, then Settings -> Project Access Tokens. Most customers will need to do this.
    • For accounts, go to Account Settings -> Account Access Tokens. Most customers will not need to do this.

Note for Heroku Users

If you’re using Rollbar through Heroku, we’ve already started the process of cycling your access tokens. We’ve created new tokens and updated them in your Heroku config. You should update the token in any other locations (i.e. development environments, and anywhere it might be hardcoded) and then disable/delete the old tokens.

Closing notes

This was painful, but we’re thankful to the security researchers who discovered and responsibly disclosed this issue, and to the security teams at Ubuntu and elsewhere who quickly released patched packages.

If you have any questions, please don’t hesitate to contact us at