News Stay informed about the latest enterprise technology news and product updates.

Fear and loathing in the Intertubes

One of the peculiar properties of the security research community is the reflexive reactions of some of its members to new work by other researchers. In most cases, researchers tend to compliment one another when they’ve produced something new. But there always seems to be a small subset of researchers who race to be the first one to point out that, regardless of the scope or originality of the work, it is: A. nothing new, B. not as severe as it looks, C. easily defended against, or D. all of the above.

The news this week about the MD5 SSL attack from Alex Sotirov, Jake Applebaum and friends brought out the knives in a sadly predictable way. The team was very careful to point out at every opportunity that its work was based heavily on the previous work done on MD5 collisions by a group of Chinese researchers in 2004, and the further work done by several European researchers in 2007. (In fact, the team that produced the 2007 work, which showed the much stronger likelihood of MD5 collisions, also worked with Sotirov and Applebaum.) The latest research simply extended the earlier work and took advantage of some advances in computing power and technology to take it a couple of steps farther than the previous research could go. But for whatever reason, that wasn’t good enough for some people.

I’ve never really understood this impulse to knock down other people’s work in order to try and look smarter yourself. How does that follow? In other news, there are a number of really well-done and readable analyses of the MD5 attack out there, starting with Eric Rescorla’s. He lays out the attack in layman’s terms and describes exactly what new contributions Sotirov and his team made. Nate Lawson also wrote a very useful description of the attack:

The attack is interesting since they take advantage of more than one flaw in a CA. First, they find a CA that still uses MD5 for signing certs. MD5 has been broken for years, and no CA should have been doing this. Next, they prepared an innocent-looking cert request containing the “magic values” necessary to cause an MD5 collision. They were able to do this because of a second flaw. The CA in question used an incrementing serial number instead of a random one. Since the serial is part of the signed data, it is a cheap way to get some randomness. This would have thwarted this particular attack until a pre-image vulnerability was found in MD5. Don’t count on this for security! MD4 fell to a second pre-image attack a few years after the first collision attacks, and attacks only get better over time.

Helpful, cogent analysis of the problem and its mitigating factors without bravado and sniping. What a concept.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

"But for whatever reason, that wasn’t good enough for some people." After all the PR & drama, I think a lot of people were expecting a more interesting attack. This one, with some very nice technical details, can be summed up as "using MD5 bad." If it was the equivalent on SHA-1, they'd deserve this amount of attention, no question.
Cancel

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly.com

  • CIO Trends #6: Nordics

    In this e-guide, read how the High North and Baltic Sea collaboration is about to undergo a serious and redefining makeover to ...

  • CIO Trends #6: Middle East

    In this e-guide we look at the role of information technology as the Arabian Gulf commits billions of dollars to building more ...

  • CIO Trends #6: Benelux

    In this e-guide, read about the Netherlands' coalition government's four year plan which includes the term 'cyber' no fewer than ...

Close