If you are running Unix and HTTPS you should review your server. If you are website user on Mac or Windows you might need to change your passwords on some of the services.
I found this good FAQ summarising the vulnerability from Reddit and thought to copy & paste here:
— clip —
What should I be doing as a user?
If you’re on Linux, update to the latest openssl libraries (ensure that the package was updated today and covers CVE-2014-0160). Ubuntu and Debian already have packages out to fix this.
If you’re on OSX, the latest openssl available there is 0.9.8, which is not vulnerable. You don’t need to update anything (unless you installed a vulnerable version manually, in which case you should update)
If you’re on Windows, it doesn’t come with openssl. If you installed it yourself (through cygwin, for example), you should check what version it is and try to update it if is a vulnerable version.
If you did have a vulnerable version of openssl installed, you should restart all of your computer applications after you update it to ensure they start using the new library.
What should I be doing as a sysadmin / website administrator / other?
Immediately update openssl libraries on any system having vulnerable versions which are hosting SSL/TLS services. Again, make sure the update covers CVE-2014-0160. If you’re using openssl 1.0.0 or older, you’re not vulnerable to this bug.
It is probably reasonable to consider any private keys from vulnerable services to be compromised, and as such you should replace those keys/certs and revoke the old certs. Failure to revoke the old cert could mean that any private keys acquired using the vulnerability could then be used to impersonate your site on the internet with full PKI trustworthiness – a very bad outcome.
Can I test to see if an external website is vulnerable to this?
Unfortunately the only way to determine if a website you don’t manage is vulnerable to this is to try and exploit it. I’d recommend against trying this unless you are fully aware of the potential legal repercussions of doing so.
What does this mean for accessing my bank / facebook / other random website?
If the website you are connecting to hosts SSL (HTTPS) and has this vulnerability, an attacker connecting to that website can view a small window (64k) of memory from the application which is terminating SSL. This window may contain a lot of things, including SSL certificates, SSL session data, or usernames/passwords, depending on the design of the terminating app.
As such, the most prudent thing to do would be to avoid connecting to those services until you can be reasonably assured that they are not affected by this vulnerability. Unfortunately this is a bit of a quagmire as determining if they’re affected is difficult to do. There is no good solution to this, other than to wait for those various websites to confirm they have fixed the issue, or to verify they aren’t vulnerable through third-parties or by testing yourself (see above regarding legal repercussions of testing yourself).
If you find that a site which you have used was vulnerable to this issue, you should change your username/password as soon as it has been confirmed fixed, for prudence sake.
Luckily most bank software is very slow to update (meaning they’re often on openssl 0.9.8, which isn’t affected), or makes use of proprietary SSL libraries, and as such it is unlikely that they are affected by this vulnerability. I’ve seen tests against a bunch of banks and saw no notable ones which are affected by this vulnerability. Unfortunately there will be some financial institutions affected by this.
— clip —
Is this a design flaw in SSL/TLS protocol specification?
No. This is implementation problem, i.e. programming mistake in popular OpenSSL library that provides cryptographic services such as SSL/TLS to the applications and services.
In following Elastica’s CTO Dr. Zulfikar Ramzan walks through the mechanics of the Heartbeat (Heartbleed) flaw (at a high level), how an attacker can exploit it, and its underlying ramifications.
See also http://heartbleed.com/