Fixing the Problems #1 – CAA

April 7, 2011 | By Phillip

Following the incident on March 15, Comodo introduced additional methods and controls immediately against this new threat vector.  On March 26 these systems detected that a further reseller was under a similar attack from what we believe to be the same perpetrator.  The new security measures protected against this attack.  Neither of these recent attacks involved the compromise of any Comodo infrastructure. Comodo has updated the incident report. We at Comodo look forward to continuing our work with all stakeholders and the security industry to continue to respond to this incident through remediation measures and set new standards to these new and emerging threats.

As the uses of the Internet change, the threat model changes. The weaknesses in the Internet infrastructure highlighted by the attack from Iran have been present for over a decade, what has changed is their significance.

Money is a fungible good and it is not worth expending $X in time, effort and resources to protect assets worth less than $X. Freedom is not a fungible good and so the threat model has changed.

If we are going to be successful we need to address the security of the system and look beyond the immediate event and the specific target. The attack highlights a weakness in the Certification Authority Infrastructure that we were already proposing to address with the Certification Authority Authorization (CAA) proposal made to the IETF, co-authored by Ben Laurie of Google.

We will look at CAA in a moment, but first lets look at the other parts of the system that are vulnerable; password authentication and code authentication.

The ultimate objective of the attack in question was to intercept communication to the authentication servers at major email providers and social networking sites, specifically to gain control of those accounts by obtaining usernames and passwords. The core weakness in the current Web authentication scheme is that the Web browser authenticates to a Web server by passing it the password. Use of SSL protects the password from interception during communication but the Web server receives the actual password typed by the user. Thus the consequence of any compromise of a Web server or an SSL certificate is compromise of the user credentials. This is an unnecessary weakness in the Internet security infrastructure and one that can be solved through some minor changes to the SSL/HTML authentication mechanism if only we could find the will to act.

The other part of the system that is vulnerable is the code authentication. One of the many services that the government of Iran offers to its citizens is a Web server offering free software. Unlike the free software provided by SourceForge and the like, this free software is mostly stolen commercial software with any copy-protection mechanisms stripped out. Experts who have reviewed the software tell me that it contains backdoors and keystroke loggers that would enable government surveillance of the use of the machine.

If we are going to be successful in defending against this new level of attack we will have to be proactive and address all three issues. A reactive approach that only addresses vulnerabilities as they are exploited will fail.

Certificate Authority Authorization (CAA) is a proposal to address the first area of vulnerability authored by myself and Rob Stradling of Comodo and Ben Laurie of Google. The first draft of the proposal was made in October 2010, before either the attack or the political events that are believed to have motivated occurred.

CAA is a mechanism that allows a domain name owner to specify which Certification Authorities and/or signature keys are authorized to issue certificates for a domain. The basic mechanism allows Certification Authorities to avoid mis-issue of certificates and for application software to avoid reliance on mis-issued certificates.

For example, imagine that Alice Corp is a 10,000 employee company with offices in 30 countries. If Carol CA requests a certificate that purports to be from Alice Corp they will validate and issue the certificate under the policy of Carol CA which might be very different from the policy that Alice Corp would want to be applied.

Large corporations that are frequent targets of this type of attack have recognized this particular vulnerability and have established sole or restricted vendor agreements with a single CA or a small number of CAs. The process of issuing certificates and management of the certificate lifecycle can then be integrated into the business processes of the customer.

Preventing mis-issue of an Alice Corp certificate by an approved CA is quite straightforward as all legitimate requests will be made through the specific processes agreed between Alice Corp and the approved CA. The problem arises when Carol CA is not an approved CA. Today Carol CA has no means of knowing that a restricted supplier policy even exists. CAA allows a domain name owner to advertise the existence of a restricted supplier policy and thus prevent mis-issue. If Carol CA is on the list of authorized Certification Authorities it will check to see that it complies with whatever additional authentication requirements have been agreed out of band. If a set of authorized Certification Authorities is published and Carol CA is not listed, the request is almost certainly fraudulent and must be refused.

In addition to making it easier for a CA to avoid mis-issue, the CAA mechanism provides an objective standard for mis-issue. If a CA issues despite a published Certification Authority Authorization set, the issue of the certificate can only be a mis-issue. Certification Authorities that persistently mis-issue are liable to find that client software providers are no longer willing to include their root Certificates or mark them as trustworthy.

CAA is thus an accountability control against certificate mis-issue. Unlike most proposed changes to the Internet infrastructure, the benefits of preventing mis-issue events can be realized very rapidly. A domain name holder does not have to wait until everyone has updated their Web browser, they will receive the benefit when Certification Authorities deploy and the latter have a very strong motivation to do so very rapidly.

If the threat model was limited to financially motivated attacks from organized crime, the accountability control alone might be sufficient. Accountability controls are not sufficient when the threat model extends to government agencies that can coerce a certificate issuer or their agent.

We can hold a person accountable for mis-issue that results from negligence or malice but the system must be robust against threats of coercion. Bank employees are told on the first day of work that if an armed robbery is attempted they are to hand over the contents of the safe and the die-pack. Attempting to resist an armed robbery is a firing offense. We need to take the same approach to Certification Authority operations: take all reasonable precautions but do not expect unreasonable ones. Banks limit thefts from armed robberies by ensuring that the amount of inventory (i.e. money) on hand never exceeds a relatively small amount.

In addition to the accountability control that provides an almost immediate benefit as soon as the necessary DNS Resource Record code is assigned, CAA allows certificate issuer restrictions to be enforced by client software such as Web browsers. To gain the benefit of this control, a user will of course need to update their Web browser. The benefits will thus be initially limited to a relatively small number of users at first, but this is an acceptable limitation since the browser users most likely to be targeted by this form of attack already know that they need to keep their software defenses current.

This last point, the fact that those targeted for government directed attacks can be expected to be early adopters for countermeasures is important because it allows us to consider other, more comprehensive measures. The vulnerability of using usernames and passwords as the basis for Internet authentication have been known for more than two decades, as has the fact that the approach adopted in the Web world, of delivering the password itself to a server for verification is amongst the worst. What has been lacking until now has been the incentive to make the necessary changes.

In the mid-1990s we faced a similar problem with Internet mailing lists. At the time all that was necessary to subscribe to a mailing list was to send a request. A few mailing list managers could send an email message to request confirmation, but this option was rarely used. Then one day some wag decided to subscribe a couple of thousand public mailing lists to each other so that a mail sent to one list would cascade through to all of the others and sign up the US White House mailing addresses to the result.

I recall that the attack began on a Friday. By the following Monday almost every mailing list on the Internet was running with subscription requests verified or with request verification enabled. Internet standards usually move pretty slowly but on occasion they can move very fast indeed. We could deploy CAA with similar speed.

In this case we need to move fast: First deploy CAA and then lets fix the Web user authentication disaster.

Be Sociable, Share!

    Add new comment

    Your name
    Comment

    You may use these HTML tags and attributes: <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>