Discovery of a memory leak bug in OpenSSL means that each and every internet user is likely to have been affected either directly or indirectly. ...
Discovery of a memory leak bug in OpenSSL means that each and every internet user is likely to have been affected either directly or indirectly.
Dubbed the “Heartbleed Bug”, this vulnerability allows stealing of information that usually would be encrypted by a secure SSL/TLS session over the internet.
Everyday Bitcoin client operation does not directly use OpenSSL, however, the Bitcoin Core 0.9.0 (and each prior version) uses OpenSSL for remote procedure calls (RPC) via https. New functionality introduced in version 0.9.0 is the ability to fetch payment requests via https and this feature is, therefore, currently insecure. Whilst the Bitcoin Core client will be updated to 0.9.1 to address the OpenSSL vulnerability, the core developers stress that the Bitcoin protocol itself is not affected by the Heartbleed bug.
SSL/TLS encryption provides secure and private communication between users and web-based services such as websites, email, instant messaging (IM), and virtual private networks (VPNs), including Tor.
The Heartbleed Bug (CVE-2014-0160) allows anyone snooping on a connection protected by vulnerable OpenSSL versions, to obtain leaked session keys and to, therefore, eavesdrop on communications, obtain data (including usernames and passwords) and to impersonate users and services.
The bug (in OpenSSL 1.0.1) was first introduced in March 2012 and has been out in the wild for two years until it was discovered and fixed on 7 April 2014.
OpenSSL’s transport layer security protocol implements a heartbeat between the client and server ends of the connection. The exploitation of this heartbeat causes memory leaks to be transmitted bi-directionally and in-the-clear between client and server.
No. It was merely an implementation problem (programming mistake) in OpenSSL versions since 1.0.1. Prior versions did not feature the Heartbleed bug.
Armed only with the intent to eavesdrop and some basic unprivileged tools an attacker can obtain secret keys used for the core X.509 certificates used by OpenSSL, and then proceed to obtain:
If you use the internet, then the answer is “yes”. OpenSSL is the most popular cryptographic library used to encrypt traffic over the web.
A recent survey reveals that open source web servers, Apache and Nginx, run 66% of websites out on the web. By default, they use OpenSSL.
The widespread use of postfix and other open-source email servers also means that supposedly secure SMTP, POP and IMAP connections have been vulnerable – all those emails being sent and received, over a period of 2 years.
OpenVPN, arguably the most popular VPN solution being offered by vendors, uses OpenSSL to secure and encrypt private WAN connections.
Tor, the darling of the Dark Web, uses OpenSSL to pass encrypted traffic securely between relays. Conceivably, with the IP addresses of most Tor relays being public knowledge, the Tor traffic of the past two years has been under a microscope, instead of the cloak that anonymous surfers assumed.
Status of different versions:
Some open-source operating system distributions that have shipped with potentially vulnerable OpenSSL version:
If an upgraded package is not yet available for your OS, software developers can recompile OpenSSL with the handshake removed from the code by a compile-time option
Consider all usernames a password used over the past two years as compromised. Whilst, not all SSL encrypted sites (https) use OpenSSL, it is difficult for the end-user to determine the exact version. Additionally, an attacker or eavesdropper leaves no known trace of their activity.
If you’re a Bitcoin Core user and you have enabled RPC via SSL, you need to upgrade to at least OpenSSL 1.0.1g and recreate your SSL server key and certificate. Users who wish to fetch payment requests via SSL should refrain from using this service until the updated core 0.9.1 has become widely adopted.
Tests for Vulnerability
Test your vulnerability by requesting a large heartbeat response. If the server replies accordingly, your SSL service is most likely vulnerable. Use one of the tests below: