Posted on 2011-04-14

On March 23rd Comodo CA Limited, a major SSL Certificate Authority, announced that on March 15th, one or more of their Registration Authorities was compromised, and a number of SSL certificates were fraudulently issued for such important sites as google, gmail, yahoo, mozilla, live.com and skype. The purpose of the compromised appeared to be the circumvention of the SSL encryption to these sites via a man-in-the-middle attack to allow eavesdropping on communications to these sites. If successfully executed, such an attack could sign malware that appeared to be official mozilla software, as well as compromising credentials and all communications via gmail, yahoo mail, and hotmail.

To understand the importance of this compromise and its possible implications, we require an understanding of what SSL/TLS is, and how it is used. The Transport Layer Security (TLS is a newer protocol that has superseded SSL, but it is still commonly referred to as SSL) is a protocol for providing secure communications between two parties over a public network such as the Internet. TLS provides 3 of the key components of information security:

• Authenticity - The identity of the party on the other end of the communication is confirmed by a trusted third party
• Confidentiality - The communication cannot be eavesdropped or read by anyone other than the intended recipient
• Integrity - The communication cannot be modified, altered or garbled en-route

So, this means that when you go to do your online shopping, at checkout when you see the padlock icon, you are supposed to be assured that the store is the real one, and that anyone sniffing your connection won't be able to see your credit card number.

The problems start when you assume the padlock means everything is safe. The padlock means that the connection is encrypted, and that a Certificate Authority (a selection of companies trusted by your browser) affirms that the server you are talking to possesses the private half of the key for this domain. You still need to carefully check that the domain is correct; it is easy to get a certificate for a misspelling of a popular site, and that certificate is completely valid. The problem is compounded by the international domain extensions that allow non-Latin characters in domain names (there is a Russian letter that looks like the Latin 'a', but which is different, and some enterprising individual registered paypal.com with the alternate letter and managed to get a certificate for it)

In the beginning, SSL certificates were hard to get, and extremely expensive. They required thorough background checks and extensive documentation. This all changed with the introduction of 'Domain Control Verified' certificates. It was decided that everyone should have access to SSL, and as long as you could prove you control the domain, you could get a certificate for somewhere around $8-$20. You can even sometimes manage to get one for free during a promotion, or on a trial basis. Originally these required telephone verification, but now all you have to do is receive an email to one of the RFC2143 addresses on the domain, or the one listed in the whois records, and you are on your way to getting a certificate.

The recent Comodo security breach brought some interesting facts to everyone's attention. It seems that the Email verification is done by the reseller, not by the CA themselves, so when one of the resellers' accounts was compromised (authentication only required a simple password), that reseller user was able to issue certificates for google, yahoo, skype, mozilla, etc without the email verification (this is done for marketing reasons; the CA sells resellers a 'white box' product that they can brand themselves, so the emails come from the reseller). This would seem to be insufficiently secure.

To combat this, Comodo is going to roll out a hardware based two-factor authentication system for its resellers, but I would still like to see the verification step moved to Comodo from the resellers. One of the problems that surfaces when trying to deal with this issue is that Comodo issues most of the certificates sold by its resellers directly from its root certificate. At the behest of Mozilla, Comodo has promised to transition to using a separate sub-CA for each reseller, a step that would make it easier to revoke or un-trust a specific reseller. The market position of Comodo, as one of the largest issuers of cheap SSL certificates, makes it impractical for them to revoke all of their certificates, especially since most of them are perfectly legitimate.

The problems stem from the fact that the certificate revocation system is broken. Rather than being able to revoke the invalid certificates that were issued, browsers had to issue an update that blacklisted those certificates, because the revocation system could not be trusted to stop them being used. This means, among other things, that certificates verified by other means, rather than in a browser, may not block these bad certificates. Microsoft issued a security advisory and update #2524375 to blacklist the certificates. The old system for revoking certificates involved each CA having a fixed URL where they published a list of revoked certificates. Your browser would periodically download this list of certificates and reject any certificates it received that matched the list. This system is being superseded by the OCSP (Online Certificate Status Protocol) which allows for the validity of a certificate to be checked in real time by a small HTTP request, rather than downloading a large CRL, parsing it, and trying to match the certificate in question against the list. Support is available in most modern browsers, but some such as safari do not ship with the feature enabled by default.

This brings us to the important issue of who decides which CAs are trusted and how do we ensure that those CAs remain trustworthy. Each browser manufacturer selects which CAs to trust based on their own criteria, although most trust a common pool of the most popular CAs. Mozilla publishes their list of requirements to become a trusted CA on this website: http://www.mozilla.org/projects/security/certs/policy/. Interestingly, the OpenSSL project, the most popular implementation of SSL does not distribute a certificate bundle, opting instead to force users to choose which CAs to trust, or to import an existing certificate list (such as the one from mozilla).

Some of these issues are solved by 'Extended Validation (EV) Certificates'. These certificates are regular SSL certificates except that a more stringent set of criteria must be met by the subject before an EV SSL certificate is issued. EV SSL Certificates also include more information about the subject, including the full legal business name, full business address and government identification (Incorporation ID). These requirements are set forth by an industry association and ostensibly enforced by the browser manufacturers who decide which EV SSL CAs are trusted. This system does a better job of verifying the identity of the subject, however it still suffers from the same issue as the regular SSL CA architecture: the lack of trust agility. With either system, the issue is that CAs have become 'too big to fail'. You cannot stop trusting a large CA without invalidating the certificates of a very large number of valid websites. According to the EFF's SSL Observatory, there are more than 4.3 million valid certificates on the publicly accessible internet, plus more on internal networks. These certificates are issued by over 650 different organizations under nearly 1500 different CA Certificates in 52 countries. Without the ability to revoke trust from the CA, there is no way to force the CAs to consider the needs of the PKI infrastructure over their own business needs. The lack of an incentive for the CAs to maintain their trustworthiness has resulting in a lot of bad behaviour, including the issuance of EV SSL certificates with incredibly low key sizes (512 bits compared to the required 2048), or the 37,000 plus certificates that the EFF found for unqualified domain names, such as 'localhost' or 'exchange'.

Another issue is that more and more certificate authorities are being pressured by governments. Especially in countries that partake in censorship, being able to get a valid Certificate Authority to issue you a rogue certificate for google or facebook would allow you to perform an undetectable man-in-the-middle attack, and intercept the credentials as well as all other data being passed between the user and the target service. In countries that do not respect human rights and freedom of the press this could result in the jailing or execution of dissidents and journalists.

In the end, SSL is what we have and it works, after a fashion, but moving forward we need stronger controls on the CAs to force them to consider the good of the infrastructure over their profit motive, or risk losing their accreditation. When a CA is trusted now, it basically must be trusted forever, or risk the wrath of the spurned customers. Some form of trust agility that doesn't break large swaths of the Internet is the only way to get away from this, but there is, as of yet, no such solution ready to be adopted.

By: +Allan Jude

Posted on 2010-04-03

A recent article by John Pozadzides only seemed to reinforce some old misconceptions about passwords and do more harm than good. Things have changed significantly and people need to be aware of the implications of changes in how passwords are stored, and in the tools that are available to crack them. Read on as I explain the ins and outs of protecting your password and the data behind it.

Read more

Posted on 2010-04-02

Crawling twitter earlier I came across a website that was offline due to a denial of service attack, and the owner was not sure when or if it would be back online. This piqued my interest and made me wonder what type of attack the site was suffering from, as some types can be successfully mitigated by experienced administrators. With this article I'll explain some of the different types of attack and mitigation techniques.

Read more

Posted on 2009-12-05

In recent days, the WyldRyde IRC network lost their services database, when one of their accounts was suspended and deleted by the shell provider. Apparently their backups of the services database were stored on that same shell account.

Read more

Posted on 2009-07-25

Network Solutions' web servers were compromised, and some extra code was added to their payment processing service, allowing the perpetrators to syphon off the credit card information for all transactions processed through the service. This breach not only affected customers of Network Solutions, but the customers of the over 4500 e-commerce sites that use the service.

Read more