Ivan Ristić

Firefox 3 improves handling of invalid SSL certificates

I have downloaded the beta of Firefox 3 to check out the improvements related to SSL. First, there's the added support for Extended Validation SSL certificates, but I am not very excited about that (I wrote about this previously in Extended Validation SSL certificates not going anywhere, as predicted). It's a nice feature, but it's not going to bring much good overall. On the other hand, I am very happy with the improvements to the handling of invalid SSL certificates.

Firefox 2.x allows users to simply click-through their way to a site that uses an invalid certificate.  There is a warning of some sort, but who reads warnings anyway? (Internet Explorer is not much better in this respect, although at least its warning is very clear about not recommending the user to proceed.)

With Firefox 3.x, the situation is much better. First you get the same style of error response as you would for any other network problem:

The beauty of this page is that it does not allow you to proceed to the site. To go through you have to create an exception, which is a multi-step process that you can start by clicking on that link at the bottom. You then get the following:

Another warning; very good. Clicking the Add Exception... button gives you the form that is used to actually create exceptions. There's a nice final warning on the top of the form, which will hopefully deter those who will be attempting to create an exception for the wrong reasons:

The changes represent a great step forward, and significantly reduce the likelihood of successful man-in-the-middle attacks. Still, I wouldn't mention exceptions at all on the error page: advanced users will find a way to do what they must, but normal users are better-off not knowing anything about exceptions.

Update (7 May 2008): My request to make hide the functionality to create exceptions from the error page was rejected. It's good to know that the issue was considered, even if the decision is not the one I would have made. Daniel Veditz pointed me to Johnath's blog post, which describes the history behind the new SSL error page. Very interesting.

 

Microsoft vs. Yahoo analysis on Marc Andreessen's blog

I don't have a habit of making posts consisting merely of links to interesting content elsewhere, but this one is just too good to pass: Marc Andreessen published an analysis of how the takeover fight between Microsoft and Yahoo may play out. Fascinating!

PCI Council clarifies Requirement 6.6, ends ambiguities

The PCI Council has just published the clarifications for the Requirement 6.6 of the PCI DSS 1.1 standard. The 8-page document dated April 15th (but not yet released in an electronic form, which is expected to happen tomorrow, on the 18th) significantly expands on the 7 lines of text of the original requirement. [Update (Apr 23): the document is now available for download.]

Overall, the clarification document comes across as very useful and well balanced. It basically lays down the options for the organisations looking for compliance, saying they can choose how to handle 6.6 for as long as they do it properly and stay within the spirit of the requirement.

Here are the highlights:

• Vendors of web vulnerability scanners and source code analysis tools are going to benefit from the clarification, because both are now explicitly mentioned as offering an adequate approach.
• Overall, I think the Council has gone to a great length to discuss how they don't want to see the automated tools (of any sort) used to just tick a few boxes away. Throughout the document they emphasize the importance of doing the job properly, and by qualified personnel. That is very encouraging.
• It is now clear that it is all right for an internal resource to perform a scan and/or a review, for as long it is not within the same organisational unit as those in charge of developing and maintaining the application.
• More than half of the document discusses web application firewalls, but doesn't really say much new, except to those who are not familiar with the technology. Although there is plenty of content—some of which is very useful—there is not enough space to cover everything one needs to know about WAFs. I think a better approach would have been to focus on what is expected of a WAF to do in the PCI role, leaving to other efforts (such as WAFEC, which is referenced in the document) to discuss what WAFs are and what they can do.
• By far the best sentence in the web application firewall section demands proper use of the technology, not mere installation: "Note that compliance is not assured by merely implementing a product with the capabilities described in this paper. Proper positioning, configuration, administration, and monitoring are also key aspects of a compliant solution." Well said. I would write it in the document in big bold letters.
• I also very much liked the mentioning of the fact that there are many products out there advertised as containing application firewall functionality, but that the organisation needs to ensure they are doing what is required from them—actually making sense of the application-layer traffic.

Overall, the document is a significant step forward. It expands what was a brief mention of several very diverse technologies into a solid recommendation how they are to be used to achieve compliance.

No such thing as Open Source business model

I started my open source project, ModSecurity, back in 2002. It was initially just a hobby, something I did in my spare time. ModSecurity grew in popularity, so in 2004 I decided to form a business around it. Thinking Stone was born. I sold Thinking Stone to Breach Security in 2006, and that was the end of my first start-up. (But not the end of ModSecurity, which continues to flourish.)

I will freely admit that I didn't have a business plan. I knew instinctively that the product was good, and I generally focused on improving the product while supporting the growing user base. Everything else I let happen organically. This "strategy" worked out all right in my case, but, in retrospective, I should have invested more effort into commercialising the user base. My luck could have went the other way just as well.

In researching how Open Source relates to business today, I've discovered a very peculiar fact: there is no such thing as an Open Source business model. There are a few companies promoting themselves as open source, but if you dig deeper you uncover that, if they are making any money, it is coming from the proprietary bits, not from open source. If there are any companies making money today from supporting their open source products, chances are they are just in a transient phase moving away from that model because there's essentially no money in it.

A typical lifecycle of an open source company looks like this:

1. Build a product people want to use. Make it free and open source, because you want to grow the user base as quickly as possible.
2. Perfect lead generation and nurturing, which is the key skill you need to have in order to be able to convert users into customers.
3. Sell training and support, because that's easy to start with.
4. Sell subscriptions, because support does not scale well and is just not sticky enough.
5. Create proprietary versions/add-ons/tools, because everything else you did so far failed to make you any real money.

It seems to me that companies are now open sourcing products because it's an effective distribution strategy, and also because they have to—everyone else is doing it. However, because there's no money in true open source, they end up selling proprietary versions, and we (the consumers) are essentially back where we were prior to the open source revolution.

Changes to British law target criminals, but affect the entire security industry

Back in 2006, at a computer security panel at Infosecurity London, I found myself criticising the proposed changes to the Computer Misuse Act (CMA), which would essentially outlaw any tool or information that could be used to assist in computer crime. Two years later things are pretty much as they were, and the changes are expected to become effective in England some time this year. They are already in effect in Scotland. There's been an attempt late last year, by the Crown Prosecution Service (CPS), to clear things up by releasing the promised Guidance to Prosecutors, but that did not help (see here and here, with additional coverage at Heise Security).

The key proposed addition in reads as follows (a marked-up copy of the changes is available, courtesy of Clive Feather):

3A Making, supplying or obtaining articles for use in offence under section 1 or 3

1. A person is guilty of an offence if he makes, adapts, supplies or offers to supply any article intending it to be used to commit, or to assist in the commission of, an offence under section 1 or 3.
2. A person is guilty of an offence if he supplies or offers to supply any article believing that it is likely to be used to commit, or to assist in the commission of, an offence under section 1 or 3.
3. A person is guilty of an offence if he obtains any article with a view to its being supplied for use to commit, or to assist in the commission of, an offence under section 1 or 3.
4. In this section “article” includes any program or data held in electronic form.
5. A person guilty of an offence under this section shall be liable—
   • on summary conviction in England and Wales, to imprisonment for a term not exceeding 12 months or to a fine not exceeding the statutory maximum or to both;
   • on summary conviction in Scotland, to imprisonment for a term not exceeding six months or to a fine not exceeding the statutory maximum or to both;
   • on conviction on indictment, to imprisonment for a term not exceeding two years or to a fine or to both.

The main issue is the ambiguity of the word likely in "[...] likely to be used to commit, or to assist in the commission of, and offence [...]", which effectively criminalises a large number of security professionals who are just doing their jobs.

As any computer security professional will tell you, criminals use essentially the same articles (tools, books, papers and sources of information) as those in charge of making things secure. Making the articles illegal is not going to stop the criminals from using them—they will be too busy committing the actual offences to care—it will just push the articles underground and out of the reach of the good guys. I am guessing the intention of the proposed changes is to reduce the availability of such "dangerous" stuff by restricting the distribution channels. That, however, is a pointless exercise, as it cannot possibly succeed.

A much bigger problem is that the new law leaves too much to interpretation. The risk is just too high: do you want to be in a position to defend your actions in front of a jury that will almost certainly fail to understand the subject matter? Even if you are successful in your defence, such an event will require significant financial resources, disrupt your life, cause you and your family endless pain, and most certainly kill your career.

What are the possible outcomes?

Possession it not likely to be criminalised (from the Guidance: "[...] does not criminalise possession per se unless an intent to use it to commit one of the other offences in section 1 or 3 CMA can be shown.") so it will probably still be safe to research computer security in private, but exchanging information with others might become dangerous. With the threat of persecution hanging over their heads, most people in the UK are likely to stop publicly discussing what they know.

Full disclosure—no matter what you think of it—will be criminalised, but it won't go away. Those who believe will continue to release vulnerability information, but they will likely take precautions to keep their identities secret.

Tool authors will have a choice to make. If they don't change their distribution practices they will risk becoming a target of investigation and, possibly, prosecution. The Guidance seems to imply the safe way to distribute the tools is via a vetted list of computer security professionals. This is not feasible for most tool writers as they cannot afford the overhead of such a process. On top of that, even if such practices are followed, there is still no guarantee that you won't be persecuted. Each case will be reviewed on its own merits. Thus the alternatives—ending further development or moving the tools underground—seem far more likely.