I just realized that I have not posted to my blog for three weeks. That is not good. Of course, I, like everyone else in the world, have been pretty busy 🙂

I traveled to Washington DC for a gathering of CIOs from other merged Library-IT organization. We belong to an organization called CLIR and we meet up twice a year to discuss various topics of interest and unique to us. I was the moderator for this past meeting. One of the most interesting topics we discussed is relevant to what we are discussing internally – library collections management. This was featured in a very interesting report from Ithaka S+R. I will write more about it in a future post. In short, all the libraries are in the process of strategizing what is the best way to manage the acquisition of and management of physical collections. Circulation statistics are on the decline, electronic versions are improving, funding is very tight and prices are going up. How do we plan for the future by taking into consideration all of these factors?

On Tuesday, April 22, I attended the gathering of several Wellesley College alumnae who were Knapp interns. Thanks to the generous support of Betsy Knapp ’64, we have been able to train several alumnae in a variety of technologies. During this gathering the alumnae explained how the experience has helped them during the course of their careers as well as in grad school. It was a fabulous gathering and it was great to hear the power of this internship experience.

I also climbed up the Galen Stone Tower on campus to see the students play the “carillons”. It was a great experience. Climbing up the tower also added significantly to the fitbit count and helped burn a few calories.

OK, if you have not heard of heartbleed bug (the media coverage on this has passed), then, congratulations to you on figuring out how to tune off from this well connected world! However, I suggest that you look at your emails to see if you got notified by anyone that you may have to change the password because their service may have been vulnerable to heartbleed.

So, what is the heartbleed bug?

When your browser communicates with a server, the information going back and forth traverses a complicated path through the public internet. This path tends to be adaptive and there is no guarantee that you will traverse the same path everytime you communicate with the same server. This actually opens up the possibility for “snooping” the information on the way. As long as the information that is being accessed is public, no one cares about snooping because it does not yield any useful information. However, when secure information travels this way, it needs to be appropriately protected, so the early developers of the web created a mechanism called Secure Socket Layer (SSL) for secure communication. This communication relies on public key cryptography, a simplified version of which is explained here. So, when you connect to a site whose URL begins in https://, it should signal that it is a secure site and that the public key cryptography is in play. If you are interested in understanding how this works, view this excellent YouTube video.

OpenSSL is an open source implementation of SSL that is pretty widespread. Even several of the commercial organizations make use of it. If you bothered to click on any of the links in the previous paragraph, you would have learned  that the communication between your browser and the web server relies on what is called a heartbeat. Basically, there are two broad classes of connections between a client such as your computer and the server. One is persistent connection and the other is not, which is usually called a stateless connection. If the connection is persistent, once establish a connection, it remains active (thereby consuming resources) on the server until the client severs the connection. Depending on the protocol and the amount of resources that gets locked up, one decides whether to be persistent or not. Given the millions of connections a web server needs to deal with, there is no point in keeping the connections persistent.

So, web server connections are stateless. You connect, you get what you want, you are done, releasing the web server to attend to the next one. When you want to go back to something more from the same server, you make a brand new connection and start all over. When you do this using SSL, there are multiple steps involved in terms of key exchange etc that requires a heartbeat check, basically making sure you get answers to things like “Server are you there?”, “Server, did you get my key?”. And the server simply responds to say yes or something equivalent. All good so far.

A couple of years ago, a programmer, working on debugging a new feature, added a piece of code to the OpenSSL server software that dumped some 64K bytes of information from the server’s memory and sent it as part of the heartbeat answer. Such debugging techniques are common when you are trying to figure out what is going wrong. Guess what? When you dump stuff from the memory of the server, it has already decrypted information that it had received and therefore your username and password and other secret information are sitting there in plain text.  The only problem is that because it is stateless, you may have connected and provided your username and password and gone away, but the next guy comes along and he potentially gets your username and password that is still in the browser’s memory! That is not good.

The problem was that the author of this bug did not remove the debugging code nor did the others who are supposed to. A major oversight that caused a lot of concern. The damage this may have caused is still unknown. This is such an obscure bug and frankly (strictly my opinion and I have been wrong before) if someone had been exploiting this during the past two years, word would have gotten around. Hackers like to boast and share their exploits with others, as you know. Robin Seggelmann, the author of this debug code, came clean and said this was purely an oversight and not malicious.

Now, though there have been some initial backlash about this and monday morning quarterbacking on how could this have happened, after people understood how open source projects work, things have quieted down. This is an excellent article that talks about the bug and how open source development works. Yes, the damage from this was significant, but if the corporations which make boat loads of money are so eager to use the open source developed products for free, one would think that they would support the open source community monetarily and also have checks and balances in place that benefits the community at large. Why would they do anything like that which cuts into their profit? With the exception of companies like Google (which does it indirectly), very few support the open source community. And in fact, I will be shocked if the powers that be in for-profit corporations have any clue as to how the open source development occurs or how much of open source code is in use within their corporations.

Open source is critical for the future of computing and whereas I don’t necessarily condone this mistake, knowing what I know, I can understand how this could have slipped through. Compared to multi-billion dollar companies like Microsoft that has created monstrous buggy software that has actually created a whole ecosystem of several other multibillion dollar companies to protect their mistakes, open source software have a far better record.

Long live open source community!