SSL certificates are supposed to provide users with assurance that the sites they are browsing are legitimate. When you go to your online banking web site via https and see the reassuring lock in the address bar which tells you that the site is really your bank, it is the SSL certificate system which provides this indication. Each certificate is signed by a series of trusted authorities which vouch for its authenticity.
When you buy an SSL certificate, the registrar from which you make the purchase is supposed to make sure that you are, in fact, who you say you are. For example, if I were to order a cert for http://www.consolidatedamalgamated.com, the registrar would require me to provide some evidence that I was in fact representing Consolidated Amalgamated and that CA was a legitimate company. Only after doing this due diligence would the signed certificate be issued, thus providing users with assurance that the sites they are visiting are, in fact legitimate.
The fragility of this system for supporting trust on the Internet was spotlighted on March 15th, when an attack on the SSL certificate system resulted in a number of fraudulent certificates being issued for sites which millions of people worldwide use every day.
The attack was detected by Jacob Applebaum, a third party security researcher who noticed that Mozilla and Google had pushed out patches to the Firefox and Chrome browsers revoking the validity of a number of SSL certificates issued by an affiliate of Comodo, one of the Certificate Authorities empowered to issue certs. Comodo (and other CAs) typically subcontract the sales and verification of SSL certs to other companies called Registration Authorities or RAs. The attackers appear to have gotten access to credentials used by one of Comodo’s RAs to request new certificates once the checks were complete. They used this information to request 9 different certificates for well known communications related domains such as yahoo.com, google.com, skype.com and live.com.
So why would an attacker do this? Primarily to be able to intercept credentials and communications between users and the web sites for which they spoofed certificates by enticing users to visit the fraudulent web sites instead of the legitimate ones. Once a user has logged on to their Yahoo Mail account via a site with one of these spoofed certs, they would see the familiar lock icon telling them that they were really talking to Yahoo and that their communications were secure, when in fact, the attackers were routing all of their traffic through systems under their control. The attackers would be able to harvest credentials and read the victims’ emails without tipping them off to the attack. The attackers also registered a certificate for “addons.mozilla.com” which would have allowed them to trick users into installing malicious browser extensions for Firefox. To top off the attack, they also registered a certificate for a new certificate authority called “Global Trustee” which would have allowed them to issue legitimate looking certificates on their own.
The Comodo attack appears to have originated from an IP address located in Iran, which raises an interesting question. Were the attackers simply run of the mill cyber criminals who wanted to use the information gathered for profit, or was this a state sponsored attack aimed at compromising the communications of opponents of the Iranian regime? Given the recent unrest in the Middle East and the key role played by social media, the Iranian government would probably be really interested in reading the mail or listening to the Skype calls of opposition figures. Of course, the attackers might have been located somewhere else and used Iranian proxy systems to make the attacks look like they were coming from Iran.
The attack points out a number of issues with the current SSL web of trust. First, the delegated nature of the system means that it is only as strong as the weakest link – in this case the security of the registration authorities. Second, the mechanism for revoking certificates has some serious drawbacks. There are basically two ways for registrars to let users’ browsers know that certificates are invalid – one method is called Certificate Revocation Lists and the other is called Online Certificate Status Protocol. In theory, browsers use these protocols to check the validity of each certificate they receive. In theory. In reality, in their default configurations, browsers will allow certificates to be used even if they are unable to get certificate status for them – this is a “fail open” situation. Should an attacker combine the creation of fraudulent certificates with a denial of service attack against a CA’s CRL or OCSP infrastructures, millions of users browsers would happily accept the fake certs without a peep.
In order to provide users with protection against this attack, the browser vendors had to issue updates to their software which included the bad certificate numbers in the local Certificate Revocation Lists. This puts the onus on the user, and I have seen enough users who don’t bother to update browser software to wonder just how many people are still vulnerable to this attack.
Requiring CAs to maintain robust infrastructures for OCSP and CRL checking by browsers and configuring browsers to require positive CA validation of certificates would go a long way towards fixing this issue in the short term, but such a solution has its own price in terms of privacy. As a result of their certificate checking functions, CAs would become able to track the web browsing habits of millions of internet users. Such a fix would also require a significant investment in infrastructure by the CAs, which could lead to higher prices for certificates.
The Internet was a very different animal when SSL was invented. Today’s internet is at the core of economic and social life and it needs to be protected in a way which is in line with that role. Hopefully, this incident will spur development of a new, more robust trust infrastructure for the internet.
RSS - Posts