Secure Web Sites Vulnerable?

by Andrew Barber 30. December 2008 09:48

Before anyone reading this sees the breathless headlines soon to come on the evening news, I thought I would post some quick analysis. In Berlin, Germany today, at the 25th Chaos Communication Congress (25C3), run by the Chaos Computer Club (CCC), a presentation was made which was entitled, "MD5 considered harmful today; Creating a rogue CA Certificate". I have no idea how the non-computer-literate (or even semi-) media will report this, but likely they will speak about SSL/Secure web sites being able to be spoofed, and that 'phishing' attacks will be more likely, and users won't have any way of knowing if they are victims.

Background

First, a quick attempt at giving a very simple explanation of what is actually very complex;

A 'Certificate Authority' (CA) is a company/entity which issues certificates that are used to verify the identity of something. Typically you will see this evident in the 'Padlock' or colored status bar of your web browser when browsing a secure web site. The 'certificate' is an electronic document, of sorts, which contains various information used to verify that the site is who it claims to be, and pointing your web browser (transparently to you) to a CA that does the actual verification. As you might expect, the identities of these CA's are very important. Every web browser comes with a pre-set list of known, trusted CA's. A user can add/remove CA's, which is a critical operation that in practice, is rarely done.

MD5 is a 'hashing algorithm". To put it extremely simply, a hashing algorithm allows you to generate a (very long) numeric value based on a set of data, where that value (the hash) can never be used to determine the original data, and where no two sets of data would ever (practically speaking) give you the same hash. This makes a hash a good value to send over a public network instead of a password, for instance. In this case, it is instead of private data that the CA holds. A hash should be able to withstand being 'publicly known', without ever revealing the data which generated it. If so, it can be used in various ways to validate identities (such as a web site), file contents, and other critical information. Since 2004, the MD5 hashing algorithm has been known to be weak, however, it has not been known that practical ways to 'crack' it existed. Nevertheless, numerous newer technologies have existed, such as SHA-1 and its variations.

A hashing algorithm is used by a CA to hash its data and data for the certificates of web sites it issues to. Many CA's today use SHA-1 or newer schemes. For example, the certificate for Amazon.com was issued by VeriSign using SHA-1. Since the aforementioned vulnerability in MD5 was announced, most CA's should no longer be using it. However, the researchers here have found a few that do, including one that has issued a great many even this year using MD5.

What Does it All Mean? What 'They' Might Say

No doubt, some media outlet will report this as an issue with secure web sites being able to be spoofed (faked), and there won't be any way for a regular user to know if it happened. You won't be able to log onto Amazon, your bank, Paypal, EBay, etc, etc, without hackers getting your precious data. Such a report will be partly true.

Other reports may go slightly further and note that only a few CA's still use MD5, and leave an inference that only sites that use those 'BAD CAs' will be at risk. Unfortunately, that particular report won't be true at all.

What Does it All Really Mean?

Practically speaking, there is nothing you can or should do about this, unless you operate a trusted CA, or you are responsible for what CA's are listed as trusted in the web browser distributions. That excludes pretty much every one of you reading this.

Right now, the sky is not falling. The researchers themselves seem to have taken care to reveal only so much as to be able to prove the concept, in order to assure that those CA's which still use MD5 will stop doing so immediately, and consider revoking and reissuing prior certificates using MD5. Assuming all trusted CA's stop using MD5 very soon, this will likely never be a real issue. The researchers here spent a lot of time and effort figuring this stuff out, and there is no reason to expect that anyone else has done so. However, the release even of the information they did gives the 'bad guys' a little bit of a leap, if they want to do so. It's up to the CA's and browser vendors to fix things first.

Regarding the second point in the above section, though; If the 'bad guys' figure out the method used here, the limited number of CA's who still issue MD5-based certificates is not a mitigating factor here. The hacker would use the exploit described here to create a 'fake', trusted CA. They would then use that fake CA to issue themselves a certificate for, say, MyBank.com. The fake MyBank.com's certificate would point your browser to the fake CA for validation, which would succeed. The 'fakes' do not need to use MD5 hashing (MD5 was only required for them to be able to steal the information to create themselves the fake CA in the first place). This is one way that browser vendors can help, though; They can pressure CA's that if they do not stop using MD5 hashing for certificates, they may get removed from their web browsers as trusted CA's, or put in warnings about any certificates which point to that CA as the validation authority. Other 'intelligent' ways for the browser to try to help can be created. However, those methods would not be perfect, and would just create more confusion for many users, so here's hoping that the CA's who still are issuing MD5-based certificates will stop right away!

Happy Surfing!

Comments

Why Eels?

No one can really be certain. But those slimey underwater critters obviously have something going for them!

Links/Profile

Andrew Barber's Profiles:
Disclaimer
The opinions expressed herein are my own personal opinions and do not represent the views of employees, contractors or clients of Inkwell Creative Group, LLC in any way.

© Copyright 2008, 2009 Andrew Barber