Heartbleed giving you heartburn? Let Silo tell you when it’s safe to return.

img_heartbleed_341x413

CORPORATE NEWS

The awareness, discussion, and swift reaction to the Heartbleed bug was remarkable. Tracking the issue through blogs, Twitter, and other feeds demonstrated the power of the collective in organizing and sharing data to respond to threats.

That’s all well and good for the technical folk who are leading the discussion and the remediation, but what about users? Heartbleed is interesting from the perspective of the end user, because there is really nothing users can do until the situation is settled. In fact, taking the right steps at the wrong time may exacerbate the exposure of user data.

I had a number of people contact me asking how they should respond. Fred Wilson even asked the question on his blog. It was great that every connected user knew they needed to do something, but it wasn’t clear what actions were right. And there was (and continues to be) a bunch of mis-information out there.

In a perfect world, a user would do 3 things before accessing a site:

  1. Check the version number of the OpenSSL library for the site (easy, right?).
  2. If the library is the most recent and up to date, proceed to step 3. If not, repeat step 1 until the answer is yes.
  3. Make sure your browser checks that the site certificate has been recently re-issued and older ones revoked. If and only then, change password (but don’t re-use the same password across different sites).

The last one (certificate validation) is an important bit. Let me explain the steps in order.

You want to change your password, because it is entirely possible that it was exposed. Ars Technica had a blog post showing Yahoo! credentials exposed through Heartbleed.

But you don’t want to change your password on a site that is still vulnerable to the exploit. Otherwise, your new password may be exposed. So you need to track the date of the underlying libraries.

Once you’ve changed your password, your data is secure. All good, right? Not necessarily. Cloudflare’s challenge proved that a machine’s certificate and encryption key can be stolen in the same manner. That means any server that was exposed could potentially be spoofed by another site, up to and including all the underlying session security.

Thankfully, most sites have revoked their old certificates and are using new versions. That’s great, but that is as far as the provider can go. Now, it is time for users to do their part. When browsers connect to sites securely, they conduct a series of queries to see if the certificate is valid. One check that some browsers perform is for certificate revocation. We explained this a bit more in a prior blog post here, but not all browsers perform this check, and it could lead to another exploit where a site with a stolen certificate could impersonate a legitimate site.

These are rather onerous steps for a standard user to take, so we’ve continued to enhance Silo to make it more seamless for users to be informed and protected. Since Silo can be configured to store credentials for websites, we have worked to integrate all the necessary steps seamlessly within a session.

With the enhancements we released last night, Silo will:

  • Check to see if a sites OpenSSL library is up to date. If it has not been patched with the latest version that prevents the Heartbleed exploit, Silo will prompt you with a warning screen.
  • Silo will continue to check sites for updates, and when the site has the latest OpenSSL library and we have checked the re-issue date of the certificate, users will get a prompt that it is safe to change their password. And of course, Silo will block access to any site using a revoked certificate.

2014-04-24_Heartbleed_Warning
Silo will prompt users with a warning when navigating to a website that has not been patched and has not had its certificates refreshed.

Having Silo perform these checks for the user and centralizing the checks across all devices, underscores a major benefit of running the browser in the cloud. With a centralized browser securing data, the user is freed from having to synchronize configuration settings across a variety of devices.

Try Silo now, and get these security benefits today, risk free.

Read the press release here.

Ramesh Rajagopal - Ramesh is Co-Founder and President of Authentic8. Before, he was VP Corporate Development at Postini, heading up strategic planning and business development until its acquisition by Google in 2007.

Topics: Corporate News