How paranoid should the average user be about heartbleed? [duplicate]

Question

Questions about Heartbleed have been showing up in the popular questions list today since morning, from the security stack exchange to android
I have been reading many of them, most of them are technical and from a server administrators perspective so difficult to understand for the average user
These are a few simple ones that I have found

1. https://serverfault.com/questions/587329/heartbleed-what-is-it-and-what-are-options-to-mitigate-it
2. How exactly does the OpenSSL TLS heartbeat (Heartbleed) exploit work?
3. What should end-users do about Heartbleed?
4. Does the heartbleed vulnerability affect clients as severely?

I do not understand the technical details, so as an average windows user, how paranoid should I be, and is there anything that I should (or can) do, if a service that I use is vulnerable?

For example, the accepted answer for item 4 above says this about vulnerable systems:

Information on common clients:

Windows (all versions): Probably unaffected (uses SChannel/SSPI), but attention should be paid to the TLS implementations in individual applications. For example, Cygwin users should update their OpenSSL packages.

OSX and iOS (all versions): Probably unaffected. SANS implies it may be vulnerable by saying "OS X Mavericks has NO PATCH available", but others note that OSX 10.9 ships with OpenSSL 0.9.8y, which is not affected. Apple says: "OpenSSL libraries in OS X are deprecated, and OpenSSL has never been provided as part of iOS"

Chrome (all platforms except Android): Probably unaffected (uses NSS)

Chrome on Android: 4.1.1 may be affected (uses OpenSSL). Source. 4.1.2 should be unaffected, as it is compiled with heartbeats disabled. Source. Mozilla products (e.g. Firefox, Thunderbird, SeaMonkey, Fennec): Probably unaffected, all use NSS

So if I am an average Windows user with chrome as default browser, I am not vulnerable? I don't think that's true so I am probably not getting something here. This page says that Yahoo is the biggest web service provider that is known to be vulnerable (also includes stackexchange). So if I have a Yahoo email or stackexchange account, does this mean my password is vulnerable from my computer's side when I type it in? In the answer that I quoted above, it says Windows and Chrome are probably unaffected as they don't use openssl. So how does this make me vulnerable when using Yahoo and stackexchange that apparently do use openssl? Is there anything I can do about it, and if so, what can I do? Change my password immediately, or wait for them to contact me, and change password after that?

I have another question. The accepted answer for item 1 has this to say:

Well, errant code in OpenSSL. Here is the commit that fixed the vulnerability. I won't speculate on whether this was truly a mistake or possibly a bit of code slipped in on behalf of a bad actor. The bug showed up in December of 2011 and was patched today, April 7th, 2014.

If the bug is that old, and it really is this serious, then why wasn't anything done till now?

Answer 1

I'll start from the bottom up :)

The bug has been present for some time, but was not discovered until recently. By definition, bugs are not obvious - they are mistakes. When it finally was found, there was a frantic effort to fix it.

The answer you linked to indicates that it is difficult for a malicious web server to attack an individuals computer, because many web browsers (which are the most common thing you would use to make a TLS connection) are not vulnerable.

However, you are still vulnerable when connected to a vulnerable server. Example: You participate in an online forum. An attacker connects to the same server using HTTPS, and using this attack, steals your session cookies from the server memory. Now the attacker can impersonate you on that forum.

Aside from not logging in to anything, there is little a non-technical end user can do at this point. It is up to the sysadmins and engineers to patch their servers. You can best help by following their recommendations if and when they are made.

Once a service has been patched, login normally and change your password. I expect that many websites will force password changes anyway after they have patched.

Answer 2

Your system isn't vulnerable to the issue as you're on Windows browsing with Chrome, but a majority of the sites you visit and use were quite possibly vulnerable.

There are several things you can do:

• Check the SSL certificates of websites you visit, make sure they have been issued after 7th April 2014
• Verify the websites you visit have been patched or aren't vulnerable (This might help: http://filippo.io/Heartbleed/)
• If they aren't vulnerable and the certificate is post-Heartbleed, then change your password (in case it was compromised)

Personally I have a Firefox addon called "Certificate Patrol", that alerts me when a certificate has been replaced or is new, which helps remind me to check to see if they're safe or not. I also have addons that identify the software running on servers, so I know if they're running a server that wasn't affected by Heartbleed (Windows Server for example, or OpenSSL 0.9.8)

If the bug is that old, and it really is this serious, then why wasn't anything done till now?

Nothing was done until now because nobody knew there was a problem until now. Unfortunately it slipped in without getting noticed - In projects that are large and have a lot of contributors, mistakes happen. It is unfortunate that it went so long without being noticed and fixed though.

Answer 3

Chrome and Firefox do not use the OpenSSL library (it uses Mozilla's NSS instead), so you as a client are not directly affected. Sites that you visit (either over HTTP or HTTPS) may leak information if they also operate listen for HTTPS requests and use a vulnerable OpenSSL version.

Yahoo was vulnerable for a long time, but it has been patched yesterday. If you have logged in via the web yesterday, consider your password compromised.

Well, errant code in OpenSSL. Here is the commit that fixed the vulnerability. I won't speculate on whether this was truly a mistake or possibly a bit of code slipped in on behalf of a bad actor. The bug showed up in December of 2011 and was patched today, April 7th, 2014.

If the bug is that old, and it really is this serious, then why wasn't anything done till now?

The bug was introduced at that time, it does not mean that the OpenSSL developers knew at that time that a bug was created.