Thursday, July 28, 2011

SSL Certificate issue: What went wrong


Last week, Comodo , one of the major SSL vendor came under the media controversy for being under attack. Comodo acknowledged that one of their Registration authority had been compromised in an attack on March 15. The attack initiated with compromise in Username and password of their south american partner organisation.
with the hacked username and password, attacker was then able to covertly issue nine digital certificate across seven domains, including: login.yahoo(NSDQ:YHOO).com, mail.google (NSDQ:GOOG).com, login.skype.com and addons.mozilla.org. The company believes
the attack -- which it traced to two IPaddresses assigned to an Iranian Internet Service Provider (ISP) -- may have been an effort by the Iranian government to spy on dissidents using Gmail, Skype and other services. But in addition to opening discussions of possible government spying, the situation also has turned a spotlight on one of the basic issues of the Internet -- proper authentication. “There really has never been an ‘SSL trust chain,''' explained Gartner John Pescatore. “SSL in practice only provides transport encryption -- it does not provide any meaningful authentication of the user and only minimal authentication of the server. It has always been way overhyped by the ecommerce world to try to overcome fears in online commerce
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..