SSL is not broken: The facts surrounding the CCC disclosure

by Steve Ragan - Jan 6 2009, 11:00

Just before the end of 2008, there was a talk given at the CCC. This talk, earning a good bit of buzz due to its secrecy, turned out to be a practical attack on SSL using MD5 collisions. Now that the talk is done, there is entirely too much FUD surrounding the issue. Here are the facts.

The Tech Herald recently sat down with Tim Callan of VeriSign. The topic of the interview -- as expected -- was RapidSSL. Later Callan discussed other things, such as Full Disclosure vs. Responsible Disclosure, and what it means to the security industry and how it impacts business.

Starting with the basics, on December 30 of 2008 at the CCC (Chaos Communication Congress) in Berlin, Alexander Sotirov, Marc Stevens, and Jacob Appelbaum gave a talk that centered on MD5 attacks, and why MD5 should be considered harmful today.

The three researchers presented a paper, co-authored by Arjen Lenstra, David Molnar, Dag Arne Osvik, and Benne de Weger, that explained how they used MD5 collisions to create a rogue Intermediate SSL certificate. The rogue certificate was made possible because of flaws in RapidSSL’s method of issuing certificates.

The Attack:

As seen in the presentation. The attack used 200 Sony PlayStation systems for the main computing power, along with the flaws in RapidSSL’s fast issuance of certificates, and created two SSL certificates that had the SAME MD5 HASH. The duplicate MD5 Hash is what makes this a collision attack.

So how was the attack pulled off? Why did the attack work in the first place? The answer to both of these questions centers on how RapidSSL itself works.

“The first big challenge was to figure out a way to predict the validity period and serial numbers of the certificates issued by a Certification Authority, since these are the only two fields in the chosen prefix that the attacker does not control directly,” the research paper explained.

This was easier than previously thought. It turned out that RapidSSL and FreeSSL, both VeriSign owned, used an automation process that issued a new certificate exactly six seconds after the user (in this case the attacker) pressed the final OK to complete the SSL ordering process. This allowed the researchers to pinpoint exactly when the validity period of any given SSL certificate would end.

The next problem they faced was the serial number. This again proved to be no challenge, as the same automated script used on RapidSSL and FreeSSL generated serial numbers in sequential order. So now all that was left was to time the purchase just right, and the attack would work.

As it turns out, the researchers needed four attempts (one attempt per-weekend), at a cost of $657.00 USD, to successfully create a collision.

“As a result of this successful attack, we are currently in possession of a rogue Certification Authority certificate. This certificate will be accepted as valid and trusted by all common browsers, because it appears to be signed by one of the root CAs that browsers trust by default. In turn, any website certificate signed by our rogue CA will be trusted as well,” the research paper concluded.

“If an unsuspecting user is a victim of a man-in-the-middle attack using such a certificate, they will be assured that the connection is secure through all common security indicators: a "https://" URL in the address bar, a closed padlock and messages such as "This certificate is OK" if they chose to inspect the certificate.”

What this attack means to the end user:

Should you panic? Is this something that will cripple SSL-based security as you know it? What if you are a large multi-million dollar company, a mid-level business or small business that demands SSL and needs it for day-to-day operations? Could this put your business at risk? Shut down your site? Compromise your transactions? Could your site become insecure?

The answer to each of these questions is no. However, considering the scope of the attack, a simple “no, you are not” to any of those questions is not enough of an answer.

Firstly, no one but the researchers can pull off this attack using the tools they created. At this time, there are no plans for the tools used by the researchers to fall into public domain.

However, collision-based attacks on MD5 have existed for years, so is it possible someone did this before the researchers? Yes, it is. Does this mean you should now panic and scream bloody murder because the Internet is broken? No it does not... and here’s why.

The attack seen at the CCC created a NEW rogue certificate. Anyone who had a MD5 certificate prior to them making their own rogue certificate is safe from this issue.

Businesses, especially the larger ones, likely don’t use certificates signed with MD5, so they are excluded from the issue altogether (EV certificates are not vulnerable to this attack, but used in big business, as are SSL signed with SHA-1).

Businesses with certificates signed with MD5 are exempt from the attack as well. This is because of the nature of the certificate that was generated by the researchers, which is an Intermediate certificate. As long as a business purchased a SSL certificated from a known and established company, even if it is MD5, then it is safe.

Bottom line, no single Web site or Web site owner is vulnerable to this attack.

So what now?

Firstly, if you have an MD5 certificate from any of VeriSign’s companies, simply re-issue it (VeriSign will allow this free of charge). This will remove any worry whatsoever, as none of the new VeriSign-created certificates are signed with MD5.

So now you know the facts about how the attack worked, if you want more details the full research can be found here.

The next page starts with Tim Callan of VeriSign and tells the company's side of the story.

At the same time attendees of the 25th annual CCC were learning about rogue certificates, Tim Callan of VeriSign was watching the same video presentation streamed live to the web.

“Very first thing… I want to confirm this is accurate,” Callan explained when asked about his first thoughts on the CCC presentation.

“Maybe it’s just me, but I’m old school and I have seen people make mistakes before and, I wanted to confirm that this is accurate. I suspected that it was because they appeared to be a pretty smart bunch.”

His second thought after seeing the presentation live? “How do we make this vulnerability go away ASAP,” Callan said.

“Within an hour of the talk being done we had confirmation at a high-level that the information [being presented was correct],” Callan explained. “Then the question was ‘what can we do?’ That’s completely what we were focused on. Until the fix was live. When the fix was live then the question became ‘okay what’s next?’”

It is common knowledge by now that VeriSign had plans to remove MD5 from RapidSSL certificates by the end of January 2009. These plans have been in place since it acquired RapidSSL. The exact phase-out date was January 15, 2009.

What wasn’t known, until today when The Tech Herald spoke to Callan, was that the fix for the vulnerability was complete. Yet the fix was being held in a freeze period.

“The reason you have freeze periods is that you don’t want to [accidentally] introduce a bug right when all of your key people are on vacation,” Callan explained.

However, while smart, these periods are negotiable. Once VeriSign learned about the talk, and viewed it in its entirety, the freeze period was over. “We actually made people come in from vacation, we took what was already ready to go, we staged it; we QA’d it, and about four hours later it was live.”

According to VeriSign, RapidSSL has now discontinued using MD5 on newly issued certificates. VeriSign will continue on its path to discontinue MD5 in all end-entity certificates by the end of January 2009.

“To be clear, there were a series of target dates over the month of January, RapidSSL was the 15th. What those dates are for is to finish removing all instances of MD5 from our full suite of SSL end code singing offerings. There are esoteric uses of SSL that still have MD5 today because we’ve been phasing it out,” Callan stipulated.

The phase-out, which he calls a spiral-outward approach, centers on the inside of the spiral (those certificates that are most valuable and of the highest priority), and fixes them first.

Yet, as Callan explained, the spiral plan was altered drastically once the talk at the CCC had finished. The mindset was, “any place where the attack that was described in Berlin could happen, has to be a high-priority and has to be resolved today.”

“However, all instances of the existing MD5 hashing algorithm are going to stay on their current end of life schedules and strategies... today [these existing instances] are scheduled to all be gone by the end of January.”

When asked if VeriSign will hit this target, Callan said, “We’re on track and we certainly believe we will.”

Another problem faced by VeriSign, as well as consumers unsure of the exact nature of SSL and what the CCC talk means to them, is FUD. Sensational headlines and news items that outlined the end of the world because of MD5-signed certificates.

“Originally when the story first got a lot of pickup, we saw headlines like ‘Online Banking at Risk’ that just didn’t really summarize the situation,” Callan explained when asked about the story's resultant FUD.

The truth is, not only were the headlines out for blood, the countless articles masking information were FUD as well. Callan noted that VeriSign saw a great deal of confusion over what this new attack meant to end-entity certificates, saying: “Our phones were ringing off the hook from our customers asking ‘what do I have to do?’ where the answer was ‘you don’t have to do anything, your certificates are unaffected by this.’”

“That wasn’t anything that the guys did wrong on stage. They didn’t get up on stage and say something that would lead people to misunderstand,” he added

The root cause of the FUD and confusion is a lack of understanding of how SSL works. The attack only created a new Intermediate CA that would only compromise an individual Web site if the SSL on that site was signed by the certificate the researchers created.

A feat that is impossible, as the researchers would never allow it, and they have withheld the tools and some of the information needed to replicate their attack. That isn’t to say that someone couldn’t have done this in the past, it’s just unlikely that they did. Yet, that argument is moot, as VeriSign has removed MD5 from RapidSSL, which is where the attack was first launched from.

At the end of the day, VeriSign is moving forward with plans to strip MD5 out completely. RapidSSL and FreeSSL customers need not worry, as they are safe from the potential harm this new attack vector can cause. Still, there is one aspect of the talk given at the CCC, and the news that followed it, that was not covered in detail and that is the subject of disclosure.

The second part of The Tech Herald’s interview with Tim Callan covers this topic, and we will post that in a separate article.

Around the Web