Ivan Ristić

Extended Validation SSL certificates not going anywhere, as predicted

According to Netcraft, there are around 4,500 web sites using Extended Validation (EV) SSL certificates, one year after this new type of certificate was introduced. At the same time, over 800,000 sites continue to use the old-style certificates. Embarassingly enough, even the certificate authorities themselves are not valuing the new technology, with some of their sites that were using EV SSL certificates a year ago reverting back to plain SSL certificates since.

This practically means the EV SSL certificates are dead. Admitedly, there is very little reason for web sites to deploy EV SSL certificates today, as the majority of users won't see any difference in their browsers. The new certificate type is supported in IE7 on Vista, with a manual update required  on Windows XP is required to enable the feature.  (Confusingly, the update didn't work for my Windows XP laptop, and I have no idea why.) Firefox, in version 2.x (the current version at the time of writing), treats EV SSL certificates as any other certificate, although version 3.x (which is around the corner) adds support. There is a very slight chance the support for EV SSL certificates in browsers will, in turn, raise interest in the technology, but I wouldn't hold my breath waiting for that to happen.

Not that it matters anyway. I wrote about EV SSL certificates last year, arguing that they are too little, too late. If we wanted to raise the level of security we should have simply mandated thorough verification of all new SSL certificates. We would have to wait for the current SSL certificates to expire, but we would eventually end up with an improved situation. With the current approach, a lot of people are going to put a lot of effort to achieve nothing: very few web site will choose to use EV SSL certificates and even fewer people will know the difference [PDF]. Phishing will continue to be a problem.

In addition to all this, EV SSL certificates are simply addressing the wrong problem. Internet needs trust, but identifying legal entities behind web site addresses is not going to help with that.  I do not need to know the identity of whoever is on the other end of the connection. What I really care about is knowing if it is safe to place the order, and this I already know how to determine with a reasonable amount of certainty: I am going to base my decision on the reputation of the merchant. In real life, I am unlikely to make a significant purchase in a seedy part of the town. Equally, online, I am unlikely to make a significant purchase from a web site I've just come across. I am going to make the large majority of my purchases with a well-know retailer, for example Amazon.com.

People prefer to make incremental changes because they are easier to do, but large problems are often too big for a series of small improvements, and require radical actions to solve.

Barracuda Networks is defending itself, the rest is spin

I've been following the Trend Micro v. Barracuda Networks case with mild amusement. (A very good overview is available at Linux.com.) Here we have a case of one U.S. company suing another U.S. company over a patent; a perfectly common affair in the U.S. legal system. Other similar disputes would normally make the headlines only to be used as another excuse to protest against the U.S. patent practice, and then quickly forgotten. Not this one. It so happens that the dispute is over a functionality which is in part provided by an open source project ClamAV, which Barracuda Networks is embedding in their appliances.

Barracuda Networks decided to spin the case to present itself as the defender of ClamAV and the free and open source world and then gave enough rope for a number of open source followers (individuals and organisations alike) to join in their defence. Some have even decided to call for a boycott of Trend Micro.

This case is indeed about patents, but not necessarily about open source. Trend Micro had previously sued both Symantec and McAfee and settled with them. Neither of these products involved open source. I think that it's reasonable to believe that Trend Micro is suing the vendors who, they believe, are infringing on their patents. Is ClamAV a threat to Trend Micro? Ultimately, I don't think it is. It is true that a large number of people is using ClamAV but those people wouldn't be buying anyway. Barracuda Networks, on the other hand, is a competitor, claiming a slice of the market. And even if the suit was about ClamAV, I doubt the open source nature of the project matters. The licence and the philosophy are not a threat, the cost—free—can be perceived as one.

Furthermore—I dare say—it does not seem to me that ClamAV is infringing. The patent concerns itself with virus-detection when used on an FTP or an SMTP proxy. ClamAV does not provide this sort of functionality on its own. To infringe it would need to be combined with other components, which is what Barracuda Networks is doing in their appliances.

While I think that, as a matter of principle, we need to stand up to unreasonable patents, and this one appears to fall into the category, we should not neglect to observe how Barracuda Networks is presenting itself in this case, using ClamAV as bait to get open source supporters on its side. They are doing the right thing—fighting rather than settling—but the spin is all wrong.

Disclosure: As of February 2008 Barracuda Networks competes in the web application firewall space. I work for Breach Security, a web application firewall vendor.

Is PCI 6.6 good for web application firewalls?

PCI requirement 6.6, which endorses web application firewalls, raises the profile of this technology but leaves a lot to be desired. Requirement 6.6 is a part of Section 6, which deals with development and maintenance of systems and applications. Sections 6.1 through 6.5 are all sound, dealing with issues such as patching, change control and secure development practices. At a glance, Requirement 6.6 seems sound too:

"6.6 Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:

• Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security
• Installing an application layer firewall in front of web-facing applications.

Note: This method is considered a best practice until June 30, 2008, after which it becomes a requirement. "

One issue with the text is that it puts two very different techniques against each other. Organisations are going to choose only one technique to achieve compliance, where, in reality, they should be using both. Looking past that, the wording works very well for web application firewalls, in the sense that most organisations are likely to choose to deploy a WAF rather than go through a very long and very expensive process of code review.

And that is exactly what causes me to worry: organisations looking for PCI certification are going to choose web application firewalls because they are the less ugly choice. Not because of the merits, of which there are many.

As someone making a living from web application firewalls, I should probably be more optimistic about the whole affair. After all, there is no doubt the level of interest in web application firewalls is rising, in no small part due to the PCI standard. The sales are increasing too. And I am sure many organisations will attempt to use the products they've purchased; some of them will like them. PCI 6.6 may actually lead to a wide adoption of web application firewalls. But it still troubles me that many of the purchases of this remarkable technology are going to be made for the wrong reasons.

At the moment the addition of web application firewalls to the PCI standard looks like an afterthought. There is a slight danger that the products will be bought and installed, but not actively used. The PCI standards needs to give WAFs at least the same treatment it currently gives to intrusion detection systems: prescribe not only the installation, but a continuous use, including various options such as blocking, detection-only deployment, virtual patching and the use of WAFs for traffic logging and monitoring.