Welcome to AppFail
You last visited: never
Cataloguing the Web's Failures.
Welcome to AppFail
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
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.
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.
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.
Posted on 2009-05-01
Everyone knows they need to select a secure password, and not write it down, but many things that people know, or are told about password security are simply not true, many times they were true at some point in the past, but they no longer apply, and are perpetuated by stale security policies, and a rigidness that can do more harm than good.
The most obvious example of this is password expiration policies. Periodic password changes were initially implemented to combat cracking, it was observed that it would take a sufficent amount of time to crack an encrypted or hashed password, and that if you changed the password every 30 or 90 days, that the cracker would be tring to hit a moving target, and this would most likely prevent the cracker from being able to find your password. Such is no longer true, with newer hashing algorithms like SHA1 and a strong password, it would take 90 computers 1000s of years to crack your password. This causes us to look at what security a password actually provides and what we can do to keep unauthorized people out of our systems.
Cuiusvis hominis est errare; nullius nisi insipientis in errore perseverare - Any man can make a mistake; only a fool keeps making the same one.
Digg Proof Hosting
The key to surviving Digg and Slashdot is Infrastructure. You can't get it from a regular web host, it requires experience. The High Load Hosting Experts at ScaleEngine can make your site thrive, and avoid having your site featured on AppFail.
Cyber Security Alerts
Page Generated in 6992ms