Since the leak got public, every IT service provider is going crazy about
the heartbleed bug that is active with OpenSSL 1.0.1 to 1.0.1f. But what
exactly makes the heartbleed bug so dangerous? This website has com-
prehensive information available for those running OpenSSL.

Since there are hundreds of thousands of websites active that use one of the affected OpenSSL versions, the chance is high, that a malicious exploit user has already taken action to successfully gain access to the private encryption key. Once one has the pkey, it is possible to fake a server’s identity with the customer not noticing this as the server is able to create valid OpenSSL-connections. The customer only sees the Lock logo indicating that all is well so far but in the background he is sending his private information to another server.

As many e-shops, e-banking websites and other protected services all run OpenSSL on their webservers, the risk is high. There’s a website to check one’s personal favourites that use secured connections if they’re exposed to the bug or really secure. Check yours here: Heartbleed check site

I found out that all of my favs are already secure. In switzerland, the MELANI office warned about the issue 48 hours ago. Yesterday most of the swiss websites have already been secured as website operators have applied the supplied patch. But there are numerous websites out in the world that may not have applied the patch till now.

So how to determine if your website’s allright?

Open the Heartbleed check site and enter the URL of the site to be checked in the form of https://<yourURL>

If the result is this (checked https://auvito.ru for example):

…it means your website is vulnerable and affected by the bug and you’re now in charge to update your OpenSSL version as soon as possible!

And if you get this:

…then all should be fine (yet it’s a good idea to update to the newest OpenSSL version if it hasn’t been done since!

But what exactly does the exploit do? Symantec has made a very clear and short description:

The malicious client sends a heartbeat request which should be usually less than 1KB in size however the header of the request asks for the first 64KB(!) of the server data.

The server then collects the first 64KB of the momory and encapsulates it into the heartbeat request.

Last, the client unpacks the heartbeat request and has now access to the 64KB of data sent back. Either you’re in luck and the memory content in the first 64KB was just garbage which ain’t of much interest or the client got sensitive information such as stored, unencrypted passwords or other secure information. The most mean thing about the heartbleed exploit is, that a server operator won’t notice traces!

And what can you do as the end user?

If you’re serious about your privacy, you can check your sites using SSL and check them with the heartbleed test if they’re vulnerable. If so, consider not using that site until they fix the exploit!