Month: December 2008

Separating fear from fact – On rogue CA certificates

Posted by – December 31, 2008

Earlier today a paper summary “MD5 considered harmful today. Creating a rogue CA certificate” and an article “MD5 collision creates rogue Certificate Authority” appeared about a presentation to be made at the Chaos Communication Congress in Berlin. John Viega commented on the issue by writing a lengthy post “The sky is not falling (re: today’s PKI attack)“. Tim Callan from Verisign soon after reverted with its response “This morning’s MD5 attack – resolved“. This post refers to implications of the same for websites and internet users the way I understand it.

What does the attack do ? The attack describes a mechanism by which a malicious user can create a rogue CA certificate and in turn create and sign tons of additional certificates which will also be rogue but which for all practical purposes shall be treated as valid certificates by a browser. It specifically refers to an attack mechanism which exploits the MD5 collision generation ease (which has been known for quite some time) and the fact that root CAs use (or now perhaps used to use) MD5 for generating the certificate digests and some predictable mechanisms for generating additional data (eg. serial numbers). While most CAs will soon plug the hole (if they haven’t already), the primary concern point relates to the fact that someone already may have created rogue CA certificates and can use that to create additional certificates at will.

I run a website with https and have a certificate. Should I be concerned ? You have a certificate that proves your credentials. This certificate continues to be valid and there is no change in its status. However there is now a possibility that someone who has setup a rogue CA can now issue additional certificates that claim to be you. Thus while this particular attack does not apparently increase your website vulnerability, it does make it potentially feasible for the rogue CA to now send your users to some other site which uses the new rogue certificate claiming to be you. However such new sites will typically use a different domain and are unlikely to use the same domain you do so long as you own and manage your website domain. Thus if your company is called ABC and hypothetically runs the website “abc.com”, another certificate could get issued by a rogue CA asserting the claims to be “ABC” running on a hypothetically different site- “abc2.com”. Users by default are unlikely to be entering abc2.com into their browser address bars to get to you and to that extent you are not so likely to be affected. Note that you are still vulnerable to phishing attack (as you were before this attack was discovered) where a malicious site “abc2.com” could send spurious hyperlinks to your user through email or websites which point to “abc2.com” which used a certificate issued to abc2.com. What this attack makes possible but only in conjunction with yet another separate class of attacks called “redirection attacks” is that a rogue certificate can now be presented to your users as “abc.com” and they will be no wiser. So in summary, most existing risks especially those related to phishing continue, but now another possibility exists whereby another site can claim to be your site and present a more authentic set of credentials that support its claim – but only in conjunction with exploiting an additional set of malicious net based attacks.

However if your certificate has been signed using md5, you should consider reverting back to your CA to replace it with a new one. This is not absolutely necessary since the existing certificates even if signed using md5 have not been invalidated or rendered insecure per se. Verisign has already suspended its normal replacement fees for such certificates. Update:Given the fact that plugins like SSL blacklist are likely to offer warnings to the end users should they come to your site, I would think that it might make sense to replace the certificates not because your current site or certificates are any less secure, but that the user’s interaction potentially could be (it is the user who runs a higher risk now).

Should I be concerned as a user ?Yes. Make sure you continue to follow all the good anti-phishing practices. Try to make sure your browsers are regularly updated with the security patches. Also make sure by either looking at the address bar (if the page is not in frames) or especially by looking at the domain name in the certificate that you are indeed communicating with a domain that you are aware of as the valid domain for the site. If the above attack has been used in conjunction with a redirection attack you are unlikely to be able to figure it out. The only way to protect yourself against such a possibility is to ensure that every certificate in the signing chain has been signed using a non-md5 algorithm (a rather onerous task to perform each time a new https connection is initiated). While I am not aware of any such existing capabilities, I would not be surprised if I start seeing either newer configuration parameters or browser add ons which disallow any https connections which use one or more md5 signed certificates in the certificate chain.

So is the sky falling ? It isn’t in the sense that existing websites or certificates haven’t become any more vulnerable. As John Viega and the original researchers point out, it is exceedingly difficult to spoof a valid already issued website certificate – it requires a specially crafted certificate request. The primary vulnerability stems from creating a rogue CA certificate and using that in turn to generate addtional rogue certificates on demand. This does allow phishing sophistication to be taken a notch higher and more difficult to detect. Given that CAs have either already or are in the process of fixing the vulnerability, newer rogue CA certificates may no longer be feasible using the attack method specified. However if and whether any current rogue CA certificates have already been manufactured is anybody’s guess (the researching attackers did create one even though it was back dated so as to be non-functional). Since this is a question that is tough to answer, probably a way to make people feel a little bit more secure is to allow a capability (configuration / addon) in the browsers to disallow / warn of any https communications with an md5 signed certificate anywhere in the chain.

Update:The following firefox addons have since the writing of this post appeared which check for md5 digests in the certificate chain.

  • SSL Blacklist 4.0 : Allows root CA certs to be md5 signed since these are not likely to be rogue certificates.

Disclaimer :I am a software architect and not a specialist security professional. These are my opinions expressed to the best of my understanding as of the time of writing this post. As in all matters related to health, law and security you should consult an appropriate professional when you need reliable advice and opinions. As with any developing piece of news, I do wonder if I might have not understood something entirely accurately. If you do find any errors or omissions, do point them out in the comments.

Will Rails go the Struts 1 way ?

Posted by – December 24, 2008

Just saw the story Merb gets merged into Rails 3. Quickly reminded me of another story that played itself out similarly around Nov. 2005 ie. Webwork Joining Struts. And there really are some parallels indeed. (Disclaimer: While I can claim to know struts quite well and webwork exceptionally well, my knowledge of Rails is limited and that of Merb is rather superficial)

  • Struts 1 was the grand daddy with a massive market share, whereas Webwork 2 was the upstart
  • Struts 1 established its dominance by being far ahead of its competition in its time. Webwork 2 was the exceptionally well designed, highly compartmentalised, granular and flexible MVC framework which clearly established a strong design lead over Struts 1
  • Struts 1 was monolithic, Webwork 2 was far more fine grained and pluggable
  • Struts 1 primarily had a single controller servlet, Webwork offered more fine grained controllers

In the post Rails and Merb merge, Katz explicitly refers to the Struts / Webwork 2 Migration. However there was one big difference, while Webwork 2 made some movement towards being just a little bit more struts like during the migration, for all practical purposes the next version after Webwork 2.2.x became Struts 2, and Struts 1 got confined to legacy. In this case it just seems unclear how Rails and Merb will move towards each other. As a designer, I really cannot imagine easily merging two frameworks and have the best of both of them be reflected in the result (it is exceedingly tough but feasible). There is a practical driving necessity of ensuring consistency which is likely to favour one of the two frameworks. I am really left with this feeling that one of them will dominate the other in the end – and this whole effort will be quite unnecessary if Rails has to dominate eventually. Definitely an interesting space to watch.

Platform Designers – Think Reach, Cloud, Usability

Posted by – December 23, 2008

A couple of days back ReadWriteWeb announced the “Top 10 Web Platforms of 2008“. I was trying to put together what it means to platform designers, and here’s my 2c worth.

Lets quickly look at the list

  1. iPhone SDK
  2. OpenSocial
  3. AdobeAIR
  4. Twitter API
  5. Facebook Platform
  6. Android
  7. Amazon Web Services
  8. Live Mesh
  9. Fire Eagle
  10. Mozilla Weave

Here’s my learning from the list :

Reach :

The most important asset a platform can provide its users is to extend reach. The number one platform iPhone SDK will not run on all OS’s, uses a rather atypical set of frameworks and languages and yet developers flocked to it. Three others in the top 5 – OpenSocial, Twitter, Facebook also allow the developers to plug into a set of existing relationships and networks and leverage them. If you want to write a platform, first and foremost see if you can extend your user’s reach – if you can, your users will come flocking.

Cloud Experience :

The cloud is here. OpenSocial, Twitter, Facebook, AWS, LiveMesh, FireEagle and Mozilla Weave all contribute to the end user having a superior cloud experience. If you want to write a platform, ask yourself if it will make things easier for the user on the cloud.

Usability and RIA :

Usability still counts for a lot. Both iPhone and AdobeAIR help make it a far superior usable experience (I can’t comment on Android yet). Moreover RIA on the desktop and mobile are still alive and kicking. If you take care of your user’s users, your users will come knocking.

Java : the perpetually undead language

Posted by – December 11, 2008

It has been quite some time that people have been coming out with statements of Java’s demise. But to see Elliotte Rusty Harold in his post Java is Dead! Long Live Python! do it caused me consternation to no end. You may want to check out his web page to get a sense of his contributions. He has written at least four books on Java including those related to XML Processing, IO, network programming. Incidentally he has also written a book on Beautiful Code (more on that later). I would suggest you read the post first, if the remainder of this post is to make any sense.

I must confess that after having spent years in Java, I like Python more. But I like Python more because of the nature of language that it is. It is natural in its flow (I like the mandatory indentations), its ultra slick programming constructs (ruby actually is a tad slicker but I dont find myself comfortable with its syntax / style and the special characters in the variable names), and its ability to really get a lot of work done with very little code. But having said that, I have no reason to believe or assume that Java is getting threatened in any particularly significant manner from these upstarts such as PHP, Python and Ruby. They are collectively not strong enough as java and are unlikely to pose a threat to Java in the market the matters the most (at least yet) – corporate enterprise software development. Corporates need comfort, and they need comfort that stems from a strong support and promise that they can count on. And they especially need that for enterprise (non workgroup / non department level) applications, and enterprise level application development hires most of the programmers (I can almost hear others starting to yell – buts its true).

I don’t intend to suggest that the newer languages cannot take on the challenges of enterprise software development. But choice of language and platforms in this context is a rather complex process – a process that involves far more than syntax and aesthetics of coding. Backward compatibility is a big deal. A very big deal in this world. You can (and I do) blame Microsoft for all its sloppy software and bloated code base but the fact remains – they made sure that they maintained backward compatibility. In fact, I believe maintaining backward compatibility and compatibility across a large number of devices is what definitely bleeds Microsoft of a lot of time and attention that they could have spent elsewhere.

So we find the academics sitting on large campuses, joined by many people in the web 2.0 / cloud computing environment and some from the workgroup / department application development space, getting gung ho about the newer languages and their cuter syntax, the brevity and the sheer power of productivity (I am one of them). But what they miss is that java solves important plumbing problems. They will realise it even more if they had attempted to deal with distributed cross platform computing in the years of yore with tools such as RPC / DCE / Encina / the various CORBA servers and services etc. etc, and deliver on the same across a whole range of platforms. Through 1996 – 2005 I believe Java solved the problem of platform independence, distribution and binary portability. And that too in an extremely impressive and credible way. You have to realise that the strength of Java is its inclusivity. It attempts to work with everyone and everybody who may want to work with it. Including those who long since adopted it in its early versions and continue to use those versions today. While many language communities attempt to crowd the etherspace with pro-my-language messages, java stands out in the fact that it doesn’t attract deliberately but it does not turn anybody away. Ever.

Sure Python 3.0 made some very welcome changes, and sure many of the changes make the code become much more intutive, but make no mistake if java generics had broken backward compatibility, its economic impact would’ve been far in excess of that triggered by all the version upgrades of Python, Ruby and PHP put together. I do believe that this approach will eventually lead to substantial subobtimisation but thats still some time away. Moreover Java needs new features and enhancements like Yul Bryner required a hair cut. Java already has so many features and capabilities, new features wont matter much in the overall scheme of things for quite some time. Java is fine, it doesn’t particularly need to grow.

Whenever I write a new application for myself, Python shall always have the first right of refusal (ie if Python doesn’t meet the requirements adequately, only then will I evaluate other languages). However when required to build an application for a customer, who wants the comfort that his application will continue to run for another 10 years at least without him having to make any changes or enhancements to the code and be able to move it around from hardware to hardware, you exactly know which language I shall choose – Java. Thats why despite all the assertions of java being threatened, and even as other languages continue to grow thanks in no small part due to the additional developer productivity promise, I think java shall remain undead for a long long time (all the versions continue to coexist). For java we shall have to say something of the sort – Java 6 is undead, Long live java 7. And 10 years from now just like today, no one is likely to lose his job for having chosen Java. Thats why I strongly believe Eliotte was so wrong.

A twitter feed in gmail : Write a google gadget

Posted by – December 10, 2008

Update: I am not yet sure why, but TwitterPane (the tool described in this post) seems to have stopped working for the moment. It might help to know that there is another similar tool out there : TwitterGadget that you can also take a look at. I would suggest that you use TwitterGadget since it is much better featured and is much more likely to be maintained. For figuring out out to write a gadget, welcome and read on.

Update: Apr 2, 2009 Deleted most of the code on the post since the article now is a little old, the code is anyway a little out of date with twitter api and most importantly since due to formatting problems was generating some very spurious html links. I did not have the time to figure out exactly why the javascript code was generating strange HTML so have for now just removed it.

The need for a twitter feed in gmail.

Lately I have started using twitter quite a bit and find myself going back to check the feed every so frequently (You can find my feed here). The other page I also visit quite regulary is gmail. While I found TweetDeck an exceptionally nice client, it starts up in a different window (thus requiring the customary Alt-Tab to switch and then to switchback) and not in my default workspace (Firefox). I started using TwitterFox extension and every so often I used to look down in the bottom right corner to check if there are any new tweets in the feed. What I wished for was getting the tweets straight onto my gmail page.

Add your own gadget to gmail.

Gmail Labs recently added a new capability to add google gadgets onto the the gmail workspace. I first checked out a few of the existing google gadgets which rolled in the twitter feeds, but soon realised that these were not designed for the narrow workspace one gets on the left hand sidebar in gmail (they were actually designed for the typical igoogle page). So I set out to create my own gadget which would be designed for the left hand sidebar of gmail and which could help serve me the twitter feeds. The real bonus about this would be the fact that I check gmail tab quite often, and I could now check the tweets at the same time.

Types of Gadget

Getting Started: gadgets.* API gets you the introductory start needed for the gadget world. Gadgets are of two types – client side and server side (my words). The client side type uses a host to serve the necessary files for the gadget as a static web server. Thus once the files are loaded onto your browser, the gadget runs on the browser and in turn makes API calls anywhere it needs on the cloud – your host is pretty much out of the way by then. The server side gadgets have some functionality that is running on the host (PHP / Python etc.). The gadget invokes these pages which in turn may make API calls from other services on the cloud. Since the twitter feed basically takes a feed from twitter using its REST API, I just needed to build a client side gadget.

Structure of a Gadget (client side)

Note that I describe a client side gadget here. A server side gadget would need all the elements I described here and would need additional scripts to be developed for execution on the server. A gadget primarily consists of an XML descriptor. In its simplest form, this descriptor can be embedded with HTML code which as we know in turn can be embedded with javascript and CSS. Thus one needs an ability to work with the languages above viz. XML / HTML / Javascript and CSS to get going with a gadget. While the google docs immediately start focusing on the XML descriptor first, I think thats really the last step in the process. You should have an idea of the screen area for which you are desgning a gadget (eg. sidebar, igoogle, full page etc.). You should also have an idea of what might be the configuration parameters that different users want to tweak when they install the gadget (eg. for twitter client an configurable parameter could be the refresh frequency). Once you have that covered, you basically are going to focus on getting the HTML/JS/CSS trio to work the way you desire. You can simply load the files off the local file system using the file:// URI, but I would recommend using a local web server such as apache.

Gadget development

1. Basic HTML

Lets first get started with the basic html file. We shall have an HTML file where we shall mark off the area using a <div> tag which shall be subsequently refreshed using javascript and the twitter REST API. we shall be using jQuery to both make the API calls and refresh the document content (the area within the “messagepanel” id). We shall also set the links to the javascript libraries, and while we are at it we shall also set a reference to the stylesheet page. (Apologies for the fact that the syntax highlighter or wordpress seem to be having some serious problems for this HTML snippet .. hence it is being rendered in a very simple fashion)

Update : Code removed as stated earlier

Thats all ? Yes, since the entire code to fetch the feed and update the display shall be in javascript. Note that you can actually bundle all this together (HTML/JS/CSS) into the outer xml that we shall write at the end, but I prefer to have it all separated out. The jquery.js refers to the downloaded jquery library file, tweetpane.js is the file where we shall be soon writing our javascript code, and tweetpane.css is where we shall be styling the display.

2. The document on load function and refresh loop
We want the javascript to kick in once the document is loaded. While javascript has a built in function for the same, I chose to use the one provided by jQuery. The first line below, asks jQuery to run the display() function after the document is loaded. The display function, selects the HTML segment identified by the id messagepanel, and embeds inside it a table tag and a span tag. The span tag has the id “messages” which shall be getting used subsequently to update the tweet data. For now we have provided a stub function getTweets() which we shall be enhancing to get the feed and update the display, but it should be noted that the setInterval() call will ensure that the feed is refreshed every three minutes. I would like to make the refresh interval configurable, but thats a todo item at the moment.

Please note that HTML / CSS is not exactly stuff I do very often. So good designers are likely to find issues in my HTML code here which they can comment on in the comments for this blog post.

Update : code removed as stated earlier

3. Getting the feed from twitter
Well we need to be be making a call to twitter API to retrieve the friends timeline. It essentially requires basic HTTP authentication for the logged in user, but we shall not have to worry about in this context since the gadget runs in the browser, and the browser shall pop up the dialog box for the userid / password. Depending upon the userid supplied by the end user, and subject to successful authentication, that user’s friends timeline shall be getting displayed. An important thing to be noted is that the url is “http://twitter.com/statuses/friends_timeline.<format>” where format is one of rss, xml, json or atom and since my favourite is json thats what we shall be using. It should be noted that when making AJAX calls, a callback javascript function needs to be provided which shall take two arguments viz. data and the error status. In this case that happens to be the populate function. Thats why you see getTweets() being only a one line function, which basically make the AJAX call, sets up the callback (populate()) and gets out of the way.

The populate() function is where much of the work gets done. We first get the HTML segment identified by the id “messages”, clear any existing contents since we shall be refreshing it regulary. The data variable contains a list of json structures which are iterated using the each() function, which splits it up into individual items, and calls the anonymous sub function. This function first identifies the css style based on the message index to separate alternate lines. It also has three regular expression matchers which try to identify twitter users (identified by a word starting with the character ‘@’), hashtags (identified by a word starting with ‘#’), and hyperlinks (the typical http/ftp/mailto links), and wrap them with the necessary code to generate the anchor tag around them to be able to make each of them into an hyperlink. Finally it composes the entire HTML code and inserts it into the segment identified by “messages” id using the append function (it actually generates a div tag for each message along the way into which it inserts one message). Since we shall be plugging this gadget into a gmail sidebar, the target of the anchor tag is “_blank” so that the hyperlinks shall open themselves into a new window (or a new tab if your browser is so configured). Moreover because the sidebar is very narrow, and many links are very long without word breaks, I had to replace the link display with a fixed “(Link)” text just so that the resultant content wouldn’t scroll off far too into the right.

Here’s the javascript
Sorry .. removed out as per update above

Note that because twitter has a limitation on the number of requests per hour, and because I wasn’t sure of how many attempts it would take me to get it right, I first use wget to obtain the output of the REST API call, stored the data in a file, and in the development stages used a link to that static file so that I wouldn’t be making calls to twitter every time I was making some minor css / html changes.

4. The gadget descriptor
In this case there was relatively little complexity to describe the gadget using the gadget xml. Here’s the xml which is largely self explanatory. The content url refers to the html page which contains the essential gadget functionality

You can pretty much get all the files by following the links from the gadget xml. These are :

In addition one basically needs a jQuery distribution to make it work.

Screenshot
Here’s the customary screenshot of how it looks in the end

Twitter Feed in GMail

Twitter Feed in GMail

Installation
Should you want to tweak the code, feel free to download and modify the files referred to and self host the gadget elsewhere. But in case you want to check it out as is, in gmail, goto “Settings” select the “Labs” tab and Enable the “Add any gadget by URL” option and press Save. You will now see a new tab called “Gadgets” under “Settings”. Go to the “Gadgets” tab and add the gadget by providing its url : http://misc.dhananjaynene.com/gadgets/tweetpane/tweetpane.xml. Thats it and thats all it takes. It will ask you for your twitter id and password to get your feed for you (and for the cautious – the gadget host neither intercepts nor stores your userid/password – thats strictly between you and twitter.)

Afterthoughts:There’s probably quite a few things I can still choose to do – clean up the HTML / CSS (some of it may not be quite upto the mark), allow configurable refresh frequencies, allow configurable form factors such as for igoogle etc. But this is fairly functional at this stage and I now can get both my frequently accessed feeds from the same page.