In last week's edition, we looked into a late-breaking disclosure of some fraudulent SSL certificates that had been issued. Due to problems with certificate revocation, it was necessary for Mozilla, Google, and other browser makers to release updates that blacklisted the certificates in question. Since that article was published, we have learned some more about the incident via postings from some of those involved. An update would seem indicated, along with some ideas of possible ways to deal with these kinds of problems in the future.

An attack from Iran?

Perhaps the most interesting update came from Comodo, which is the certificate authority (CA) that is responsible for the fraudulent certificates. Based on the information Comodo gathered from the attack, it would appear that the attacker was based in Iran. The set of domain names for which fraudulent certificates were issued (mail.google.com, www.google.com, login.yahoo.com, login.skype.com, addons.mozilla.org, and login.live.com) strongly point to a government-sponsored attack. A "regular" criminal attacker would seem more likely to go after certificates for banks and payment sites, but that is circumstantial evidence at best.

Another interesting, if unconfirmed, update is the message from the "Comodo hacker". That message indicates that the Comodo partner (the InstantSSL.it registration authority) had some alarmingly lax security. It also claims that the attack was not sponsored by the "Iranian Cyber Army", and was, instead, just the work of single person. The message contains fairly convincing sounding details of the attack, but there has been speculation that it could have come from the Iranian government as it tries to cover its tracks. We may never know the truth of the matter, as there are interests on all sides with reasons to obfuscate. Authentic or not, the lack of security attributed to the registration authority unfortunately rings true.

Mozilla also followed up its earlier message about the certificates with a recognition that the project should have been more forthcoming. Withholding information about the existence of the fraudulent certificates was really only helpful to the attacker. Knowledge of the certificates would have allowed users to make their own decisions about mitigating the threat posed by a man-in-the-middle (MITM) attack that used them.

Mitigating the risks

MITM attacks are, by their very nature, focused on a small subset of the internet—or a small subset of its users—as the risk of detection rises as a function of the number of users affected. That means that checking certificates from multiple locations in the internet will be quite successful in detecting a local MITM attack. That is exactly what the Perspectives project is working on.

The project provides multiple "network notaries" that are located in different places, both physically and based on internet routing, which monitor the certificates presented by different sites. These notaries store the certificate fingerprint, along with a date and time, so that they have a history of the certificates presented by a given site. When a client wishes to connect to a domain using SSL, it can compare the certificate fingerprint it gets with those stored by several notaries. If they all match, the chances are extremely low that there is some kind of MITM attack going on.

Rather than doing all of that checking manually, though, the project has a Firefox extension that will do that checking, and alert the user if it detects something has gone awry. In addition, the Perspectives extension can override the Firefox error page that comes up for self-signed certificates if it finds that multiple notaries have all recently seen the same certificate.

Obviously, clients must make secure connections to the notaries, so that the attacker can't just spoof their response, so the notary list includes each notary's public key. In addition, notaries could keep track of the responses of other notaries so that malicious notaries could be detected. Each notary would act as a "shadow server" for several other notaries, and clients could check with the shadow server to ensure that the information it received is consistent with what the notary has reported in the past. The shadow server idea is described in the Perspective paper [PDF], but does not seem to be implemented yet. If and when notaries that are not under the control of the project are added, one would imagine that shadow server functionality would be added.

Detecting changed certificates

A simpler mechanism for detecting possible MITM attacks is embodied in the Certificate Patrol Firefox add-on. Essentially, it locally keeps track of which certificate has been seen for a given domain, and alerts the user if that certificate changes. The idea behind it is "trust on first use" (aka TOFU), which means that the first time a valid certificate is seen, it should be trusted. Certificate Patrol (CP) does display the certificate information it receives on first use so that the user can potentially note any red flags. If ever the certificate changes down the road, though, the user will be alerted to that change.

There are plenty of valid reasons why a site might change its certificate, however, so there could be various false positives from CP. When a certificate changes, CP will examine the new certificate and rate the likelihood that it indicates some kind of attack. For example, CP tries to detect certificates that were replaced because they were near to their expiration, and rates that change appropriately. It also tracks the CA used to sign the certificate, as a new certificate from the same CA as the old is less likely to have been issued fraudulently.

One good outcome of the attack

One good thing that resulted from these fraudulent certificates is that folks are thinking and talking about better ways to handle problems like that in the future. Some would claim that the CA model is broken, but we have to have something to replace it before we can even consider dumping it, or reducing its role. Neither Perspectives nor Certificate Patrol are targeted at that particular problem, but may provide reasonable stopgap measures for now.

Toward the end of Jacob Appelbaum's post outlining his detective work in discovering that there were fraudulent SSL certificates floating around "in the wild", he mentions a number of proposals and projects that might offer some alternatives to the current system. We looked at one of those, Monkeysphere, early last year. The others he mentions, DANE, CAA, and HASTLS seem worthy of a look at some point as well. There were already plenty of grumbles about the CA system before this particular incident, but the volume of those complaints is growing, so thinking about alternative solutions is certainly useful.