Before I start, let me; let everyone know that I’m not a fan of opensource, to the extent that you can call me anti opensource.

So, on 7th April 2014, the world woke up to heartbleed, a vulnerability in the VERY popular openssl software which is used by almost the entire world to secure their websites and systems. When I say the entire world, it includes giants like Google, Facebook, Yahoo, Netflix, Adobe and Paypal to name a few. Openssl is an opensource cryptographic library used to implement Transport Layer Security (TLS), known previously as Secure Socket Layer (SSL). In simpler terms, it’s the very engine that makes your secure websites and servers “Secure”, so a critical vulnerability being found in openssl means nothing less than Armageddon, and Armageddon it is since the last two weeks in the digital world.

The bug was discovered by Neel Mehta of Google Security on 1st April 2014 (All Fool’s Day) but was made public seven days later. Some engineers (Riku, Antti and Matti) at a Finnish Security Firm called Codenomicon discovered the same bug on 3rd April, unaware that Google had already found it three days earlier. The term “Heartbleed” was coined by Ossi Herrala, a systems administrator at Codenomicon. The name heartbleed refers to an extension of openssl called hearbeat, it is used to keep connections open, even when there is no activity between the client and the server, Herrala thought it was fitting to call it Heartbleed because it was bleeding out the important information from the memory, let me try to explain how. By the way, Mehta donated the $15,000 bounty he was awarded for helping find the bug to the Freedom of the Press Foundation’s campaign for the development of encryption tools for journalists to use when communicating with sources.

The RFC 6520 Heartbeat Extension tests TLS/DTLS secure communication links by allowing a computer at one end of a connection to send a “Heartbeat Request” message, consisting of a payload, typically a text string, along with the payload’s length as a 16-bit integer. The receiving computer then must send the exact same payload back to the sender.

The affected versions of OpenSSL allocate a memory buffer for the message to be returned based on the length field in the requesting message, without regard to the size of actual payload in that message. Because of this failure to do proper bounds checking, the message returned consists of the requested payload followed by whatever else happened to be in the allocated memory buffer. The problem was compounded by OpenSSL’s decision to write its own version of the C dynamic memory allocation routines. As a result, the oversized memory buffer returned to the requestor was likely to contain data from memory blocks that had been previously requested and freed by OpenSSL. Such memory blocks may contain sensitive data sent by users or even the private keys used by OpenSSL. In addition, by using its own memory management routines OpenSSL bypassed mitigation measures in some operating systems that might have detected or neutralized the bug.

The heartbleed bug is exploited by sending a malformed heartbeat request with a small payload and large length field to the server in order to elicit the server’s response permitting attackers to read up to 64K bytes of server memory that was likely to have been used previously by SSL. Attackers in this way could receive sensitive data, compromising the security of the server and its users. Vulnerable data include the server’s private master key which would enable attackers to decrypt current or stored traffic via passive man-in-the-middle attack (if perfect forward secrecy is not used by the server and client), or active man-in-the-middle if perfect forward secrecy is used. The attacker cannot control which data are returned, as the server responds with a random chunk of its own memory.

The bug might also reveal unencrypted parts of users’ requests and responses, including any form post data in users’ requests, session cookies and passwords, which might allow attackers to hijack the identity of another user of the service. CVE-2014-0160 has been assigned to this vulnerability. At its disclosure, some 17 percent or half a million of the Internet’s secure web servers certified by trusted authorities were believed to have been vulnerable to an attack. The Electronic Frontier Foundation, Ars Technica, and Bruce Schneier all deemed the Heartbleed bug “catastrophic.” Forbes cybersecurity columnist, Joseph Steinberg, described the bug as potentially “the worst vulnerability found (at least in terms of its potential impact) since commercial traffic began to flow on the Internet.”

The vulnerability was introduced into OpenSSL’s source code repository on December 31, 2011 by Dr. Stephen N. Henson, one of OpenSSL’s four core developers, following a request from Dr. Robin Seggelmann, the change’s author. The vulnerable code has been adopted to widespread use with the release of OpenSSL version 1.0.1 on March 14, 2012. Dr. Seggelmann, the German Programmer who wrote the code (are the Germans going to cause another world war? This time in the digital world?? 😉 ) worked for the OpenSSL project while getting his Ph.D. studies from 2008 to 2012 at University of Munster. Adding to the drama of the situation, he submitted the code at 11:59 p.m. on New Year’s Eve 2011, though he claims the timing has nothing to do with the bug. “I am responsible for the error, Because I wrote the code and missed the necessary validation by an oversight. I failed to check that one particular variable, a unit of length, contained a realistic value. This is what caused the bug, called Heartbleed,” said Seggelmann, now an employee with German telecommunications provider Deutsche Telekom AG.

He said the developer who reviewed the code failed to notice the bug, which enables attackers to steal data without leaving a trace. “It is impossible to say whether the vulnerability, which has since been identified and removed, has been exploited by intelligence services or other parties,” he said.

Now, providing you with all the info given above is not the reason why I’ve written this blog, it is to highlight one simple fact, that you can’t trust anything that is open source. This entire open source phenomenon started right in front of me but unlike everyone else, I was never excited about it, the whole world going mad about this open source thing looked very weird to me at that time and the feeling is still the same. I used to share my thoughts with my peers but nobody used to agree with me, I used to sign off with a statement that one day this whole open source thing will cause trouble for all of us, BIG time, I could see that they thought that I’m a weirdo but then I was ok with that because I’m not a person who would change his thought process just because everybody else thought differently, it’s difficult to swim against the tide and you have no company, you are alone but if your will is strong enough, you will make it to the shore.

Now, the heart of the open source community is bleeding and it’s bleeding heavily in the open. Something like this was bound to happen, it was nothing but imminent, just a matter of time as they say. Free stuff excites everybody but all of us should always remember that there are no free lunches in this world. If you are getting something for free, you’ve got to doubt it. These open source fanatics call Microsoft all kinds of names for their heavy licensing costs and it looks very weird to me, If I create something of great value then I would like to get paid handsomely for that, I believe in philanthropy but giving away my valuable work for free doesn’t qualify as philanthropy for me. Even as a user, if I could compare buying software with buying a car, I would like to buy a car from a very reputed brand like Ford, General Motors, Chevrolet or Honda and not a car built by my neighbourhood mechanic in his garage. Those big brands will charge me big bucks compared to the mechanic but I’m sure that the branded car is still going to be a better deal. I always thought that the open source only looks good to novice users and to the people who think that they are great technocrats but don’t really know anything about it, reading four blogs a day doesn’t make you a techie. I’m still ok with someone liking the concept of opensource but when people started to dish out all the open software, that again proved my point that all that was nothing but crap. To give you one very simple example, when firefox came out, it was tagged as being way faster than Mircrosoft’s IE, but the firefox programmers were doing nothing but just trying to make a fool out of their users. When you close firefox, it disappears much faster than IE does, and it indeed happens but it does just that, it just disappears from the user’s view, it doesn’t get closed any faster than IE, if you try to open firefox again right after closing it, you would get an error saying that another instance is already running, if you go to the task manager, you will be able to see the process still running. This is nothing but gimmickry and the novice users and the world’s great technocrats still think that firefox or chrome are better browsers than IE because they are fooled by the eyewash that these opensource guys indulge in. I always thought that even on the security front, these browsers are no good but I never tried to do any kind of research into that, mainly because I was just so sure of it. I always tell my wife to never use firefox for any online shopping, bill payments or net banking. Now, this heartbleed bug has once again confirmed my theory that open source software is less secure, here’s how. Any website would need to do the following to get around this heartbleed.

• Upgrade their server software to a non-vulnerable version. I can’t give you general advice on how to do this because it depends on which software you are running.
• After upgrading your software, generate a new SSL/TLS key and get a certificate for the new key. Start using the new key and certificate. (This is necessary because an attacker could have gotten your old key.)
• Revoke the certificate you were previously using. (This is necessary because an attacker who got your old key could be using your old key and certificate to impersonate your site.)
• Have your users change the passwords that they use to log in to your site. (This is necessary because users’ existing passwords could have been leaked.)

However, even if all of the affected certificates were to be revoked, contemporary web browser software handles certificate revocation poorly. The most frequent users of a site — often its administrators — can continue using a revoked certificate for weeks or months without the browser notifying them that anything is amiss. In this situation, an attacker can perform a man-in-the-middle (MITM) attack by presenting the certificate to unsuspecting users whose browsers will behave as if they were connecting to the legitimate site. For example, some browsers only perform OCSP revocation checks for Extended Validation certificates, while others ignore certificate revocation lists completely. SSL Certificates are used to secure communication between browsers and websites by providing a key with which to encrypt the traffic and by providing third-party verification of the identity of the certificate owner. There are varying levels of verification a third-party Certificate Authority (CA) may carry out, ranging from just confirming control of the domain name (Domain Validation [DV]) to more extensive identity checks (Extended Validation [EV]). However, an SSL certificate — or any of the certificates which form a chain from the server’s certificate to a trusted root installed in the browser or operating system — may need to be revoked. A certificate should be revoked when it has had its private key compromised; the owner of the certificate no longer controls the domain for which it was issued; or the certificate was mistakenly signed. An attacker with access to an un-revoked certificate who also has access to the certificate’s private key can perform a man-in-the-middle (MITM) attack by presenting the certificate to unsuspecting users whose browsers will behave as if they were connecting to a legitimate site. There are two main technologies for browsers to check the revocation status of a particular certificate: using the Online Certificate Status Protocol (OCSP) or looking up the certificate in a Certificate Revocation List (CRL). OCSP provides revocation information about an individual certificate from an issuing CA, whereas CRLs provide a list of revoked certificates and may be received by clients less frequently. Browser support for the two forms of revocation varies from no checking at all to the use of both methods where necessary.

Firefox does not download CRLs for websites which use the most popular types of SSL certificate (all types of certificate except EV which is usually displayed with a green bar). Without downloading the CRL, Firefox is happy to carry on as usual; letting people visit the website and transfer sensitive personal information relying on a certificate that is no longer valid. In any case even if OCSP were available, by default Firefox will only check the validity of the server’s certificate and not attempt to check the entire chain of certificates (again, except for EV certificates). Google Chrome, by default, does not make standard revocation checks for non-EV certificates. Google does aggregate a limited number of CRLs and distributes this via its update mechanism but it’s not very efficient in that area. For the majority of Chrome users with the default settings, as with Firefox, nothing will appear to be amiss. For the security conscious, Google Chrome does have the option to enable proper revocation checks, but in this case the end result depends on the platform. On Windows, Google Chrome can make use of Microsoft’s CryptoAPI to fetch the CRL and it correctly prevents access to the site. However, RSA’s CRL is not delivered in the conventional way: instead of providing the CRL in a binary format, it is encoded into a text-based format which is not the accepted standard. Mozilla’s NSS — which is used by Firefox on all platforms and by Google Chrome on Linux — does not support the format. On Linux, Google Chrome does make a request for the CRL but cannot process the response and instead carries on as normal. Microsoft’s web browser, Internet Explorer is one of the most secure browsers in this context. It fetches revocation information (with a preference for OCSP, but will fallback to CRLs) for the server’s certificate and the rest of the certificate chain. Now, I think that should make my wife proud of my advice to her 😉

All this gimmickry and all these security flaws in the open source software stem from the fact that the motto of all these guys is NOT to make great software, rather it is to just make something that at least ‘looks’ better than MS products. It’s always easy to build your product that betters on the competition’s flaws or at least perceived flaws, for example, what makes IE a tad bit slower than some of these so called faster browsers is things like I just explained above and these things are not only in the security area, they are in all perceivable areas. If I have an accident in my branded car, I will have better chances of being alive than in the car that a mechanic built, overlooking and compromising on the safety features to make his car cheaper and faster. Microsoft’s Implementation of SSL/TLS remains completely unaffected by this bug and while people might tell me that OpenSSL is a respected opensource software (or at least it was, till the time it’s heart bled), I would argue that the reputation is based largely on wishful thinking and open source mythology. What good can a software be that is made by a small group of developers, most volunteers and all but one part-time. Huge parts of the Internet, multi-zillion dollar businesses, implicitly trust the work these people do. Basically because of only two factors a) It’s free, b) It’s open source, the code being available freely makes people think that a lot of people would be able to review it and find bugs, but since the discovery of this heartbleed bug took years to be discovered (which was not a highly complex miss to find, instead it can even be called a silly programming mistake) we now know that it’s more of a myth than a reality. So, just to save a few millions, enterprises have chosen to put their prestige at stake. It just never ceases to amaze me.

You might think that at least now these big guys might just stop trusting opensource with their life and start paying up for better software but I don’t think that it’s still going to happen because a)heartbleed, even after all of it’s popularity, still remains a bug known only to geeks, b) People think that lightening doesn’t strike the same place twice. So, in my opinion, these people are not going to learn unless something more devastating happens yet again which makes people lose money from their bank accounts and make them lose their emails and other confidential data. So, my advice to all of you is don’t take that car from the neighbourhood mechanic even if he gives it to you for free.