A tag cloud with terms related to Web 2.

Image via Wikipedia

From Web 2.0 era to the current SaaS era, we are seeing a proliferation of Mashups, not just in the consumer space but also in the enterprise space. Well, the idea of mashing up of data from two or more data sources/applications is not unique to these times. We have seen such mashups even during the traditional computing era but what makes this attractive is the availability of such mashups over the web for consumption using web browsers or Rich Internet Applications. For example, when you check the weather on a website by inputting the zipcode, it picks up weather data from one application and map data from another application, mashes it up and presents the result to the user through the browser. This ready availability of mashups over the web poses some security problems and one such problem is going to be the topic of this post. First, let me describe the problem and, then, talk about one of the solutions considered by a industry consortium.

In the more traditional web era, which some people dub as Web 1.0, the security and integrity of the data moving from the data source (server) to the browser (client) was mediated by the Secure Socket Layer, popularly known as SSL. SSL protocol helps us establish a secure channel between two entities but it doesn’t help when more than two entities are in play, as in the mashups. Even though there are reports about the possibility of compromising SSL to attack such two party web communications, it has served us pretty well so far. SSL prevents the man in the middle attacks by using TCP as a communication layer and public/private key encryption, to provide a reliable end-to-end secure and authenticated connection between two points over the internet. SSL uses public and private key to establish a trust through a handshake between two entities. Once the handshake is completed, these entities can securely transfer data without any worries.

However, SSL doesn’t scale to mashups and other SaaS interoperability use cases. In the case of mashups (and, of course, in SaaS interoperability scenarios), two or more application communicate with each other through the user’s browser. There is no standard way for these applications to authenticate each other and establish a secure communication channel. From the consumer SaaS applications to Enterprise 2.0 applications, we are now seeing some kind of mashup of data sources from different applications. When two applications connect with each other through the user’s browser, how can these applications be sure that it is not a man in the middle sitting to either grab the data or inject “bad” data or a browser infected by malware capturing important data and sending it to “bad hands”? Since mashups happens at the application layer, there is no easy way to authenticate and establish trust. SSL doesn’t help in the multi-party situations as, by definition, it is supposed to stop multi-party situations like man in the middle attacks. Moreover, SSL mostly works on the TCP layer and cannot help much in the case of mashups (Security gurus, feel free to point out any situation where SSL could be tapped to solve the mashup needs but I haven’t come across any such situation).

To solve this problem, we can go ahead and develop a protocol and standardize it but it is time consuming. In this era of faster adoption of such technologies by users, especially enterprises, there is a need to find an alternative solution. The solution should be

  • Simple and with no complex needs for new cryptographic techniques or protocols. Such new technologies delays adoption as trust is not something that can be gained fast.
  • Must be RESTful so that it is lightweight and can sit on top of ubiquitous http
  • Not requiring any changes to the browser because it will also delay the adoption
  • More importantly, it should be able to scale well in this cloud based world
  • Definitely open and, preferably, under one of the OSI approved licenses

Enter MashSSL, an alliance formed by a consortium of leading technology companies including leading SSL certificate vendors Comodo, DigiCert, Entrust and VeriSign; leading providers of security technology and services Arcot, Cenzic, ChosenSecurity, Denim Group, OneHealthPort, QuoVadis, SafeMashups and Venafi; leading security research institutions Institute for Cyber Security, UTSA, MIT Kerberos Consortium and Secure Business Austria, along with noted security experts in November, 2009.

MashSSL is a new multi-party protocol that has been expressly built on top of SSL so that it can take advantage of the trust SSL already enjoys. MashSSL is based on an unique insight which uses deliberately introduced trusted Man in the Middle entities which could manipulate the messages but eventually cancelling out the effect of such manipulations so that the two applications always receive the exact data they would have got in the absence of such Man in the Middle entities. This whitepaper explains this very well with some neat case studies.

MashSSL was first developed by a company called SafeMashups and has now become an open specification with an open source reference implementation, and is in the process of being standardized. Essentially, MashSSL repurposes SSL to create a secure application layer pipe through which open protocols like OAuth, OpenID, OpenAJAX, etc., and proprietary applications like payment provider interfaces can flow in a more secure fashion while leveraging the already existing trust and credential infrastructure.

As I concluded in one of my recent posts,

With Web 2.0 and SaaS, we are mostly seeing adoption by geeks and pundits. There is no widespread adoption from mainstream consumers yet and only a small segment of businesses are using them. With more and more adoption of these technologies, such attacks are only going to increase. If these providers don’t have the security (infrastructure, application, people, etc) correct, we are going to see large scale attacks and chaos.

Mashup security will become crucial with further adoption in both consumer and enterprise space. Especially, in the case of enterprises where critical data are mashed up for gaining valuable business intelligence, this security between various data sources and/or applications becomes one of the most important issues. This issue should be giving the CIOs and CSOs nightmare. With further tweaking of the MashSSL proposal and standardization, they could mitigate a big chunk of the risks involved.

PS: This is my attempt to simplify the complex security issue for the consumption by our readers. If I have missed out any crucial information, feel free to jump in and add your comments. This post was motivated by a note posted by Christofer Hoff in his blog.

CloudAve is exclusively sponsored by

Krishnan Subramanian

Krish dons several avatars including entrepreneur in exile, analyst cum researcher, technology evangelist, blogger, ex-physicist, social/political commentator, etc.. My main focus is research and analysis on various high impact topics in the fields of Open Source, Cloud Computing and the interface between them. I also evangelize Open Source and Cloud Computing in various media outlets, blogs and other public forums. I offer strategic advise to both Cloud Computing and Open Source providers and, also, help other companies take advantage of Open Source and Cloud Computing. In my opinion, Open Source commoditized software and Cloud Computing commoditized computing resources. A combination of these two developments offers a strong competitive advantage to companies of all sizes and shapes. Due to various factors, including fear, the adoption of both Open Source and Cloud Computing are relatively slow in the business sector. So, I take it upon myself to clear any confusion in this regard and educate, enrich and advise users/customers to take advantage of the benefits offered by these technologies. I am also a managing partner in two consulting companies based in India. I blog about Open Source topics at http://open.krishworld.com and Cloud Computing related topics at http://www.cloudave.com.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.