Share this post on Twitter


Andy Brody on April 9, 2014

By now, you’ve probably been bombarded with announcements about the Heartbleed bug from a number of different sources. People have released vulnerability-checking tools, walkthroughs of the vulnerable code, and commentary about the overall implications of this bug.

The long and short of it is most of the known Internet was vulnerable to Heartbleed. Most SSL bugs only allow attackers to intercept encrypted data. This one was more severe because it also allowed an attacker to read the memory of a remote SSL process, meaning that cryptographic keys could also have been compromised.

While we have no reason to believe that this vulnerability has been used to attack us, we take a very cautious approach to security. Sometimes that’s adding to the Chrome HSTS pre-loaded list; sometimes that’s tuning our ciphers for perfect forward secrecy (which prevents an attacker with your compromised keys from decrypting past SSL sessions). In this case, it was responding under the assumption that public exploits were just hours away.

Our response

One of the most important responsibilities of a security team is to respond to critical vulnerabilities as quickly as possible. With a bug like Heartbleed, there’s a limited window between when the vulnerability is announced, public patches are released, and exploit code becomes freely available for any script kiddie to use. The right strategy is sometimes to wait for vendor-supplied packages to be available, but in other cases (such as with the CRIME vulnerability) we’ve been able to patch faster by building our own packages.

Here was the timeline of our response (all in Pacific time on Monday):

  • 11:29 AM: We were alerted to Heartbleed. We noticed Ubuntu had yet to release packages, so we proactively started building our own.
  • 2:30 PM: Shortly after we finished building our packages, Ubuntu released theirs.
  • 3:45 PM: We had fixes rolled to all our Internet-facing servers.
  • 4:10 PM: The first public exploit code we know of was released.

Since then, we’ve worked around the clock on rolling our SSL keys, upgrading our internal servers, and revoking the old keys (all now completed). We’ll be invalidating all existing login sessions shortly, so don’t be surprised if you have to log back into your Stripe account. We are also upgrading our client libraries to support certificate revocation; we’ll post an update when this is done.

What you should do

Here are some concrete steps you should take to improve the security of your Stripe account:

  1. Change your password: Remember to use a unique password rather than sharing across sites.
  2. Enable two-step verification: This will make it harder for attackers to access your account if your password is compromised.
  3. Rotate your API keys: As an added security measure, we’ll start recommending that all our users roll their keys at least every 6 months.

In the coming days, we’ll send out an email to all of our users describing these steps in more detail.

If you have any questions or concerns, please don’t hesitate to get in touch.

Further reading

  • Matthew Green has a good blog post explaining Heartbleed and its implications.
  • The Hacker News thread about Heartbleed is quite informative.
  • Stripe CTF and Stripe CTF 2.0 both are good ways to get hands-on experience with security vulnerabilities like this.
  • Adam Langley’s blog is a great source on SSL internals. (Adam was incidentally one of the co-authors of the Heartbleed patch.)