Site Certificates Forged; Internet Security Not So Secure

from the lock-and-key dept

Ed Felten has the details on a rather worrisome bit of information released by some security researchers on how to forge site certificates. Generally speaking, secure certificates for sites were considered to a pretty definite sign that you were safely connected to a particular site — and transferring any data between you and that site securely. The ability to forge such certificates throws all that into doubt, and it severely disrupts the ability to be confident in a secure transaction online. Felten describes how this is fixable (though, some certification authorities should have made changes a while ago to prevent this), but it’s yet another reminder that what’s secure today might not be so secure tomorrow.

Filed Under: , ,

Rate this comment as insightful
Rate this comment as funny
You have rated this comment as insightful
You have rated this comment as funny
Flag this comment as abusive/trolling/spam
You have flagged this comment
The first word has already been claimed
The last word has already been claimed
Insightful Lightbulb icon Funny Laughing icon Abusive/trolling/spam Flag icon Insightful badge Lightbulb icon Funny badge Laughing icon Comments icon

Comments on “Site Certificates Forged; Internet Security Not So Secure”

Subscribe: RSS Leave a comment
11 Comments
Anonymous Coward says:

This is just another reason why successful technology evolves – we’ve known since 2004 that someone with enough processing power could generate a duplicate MD5 hash. While competition isn’t currently as much of a motivator in this particular subfield of security, if we allow our computer security technology to sit and age, it will eventually be made obsolete by increased processing power and new research. It is nice to be able to rely on one function for such a long time, but just because it is reliable at the moment doesn’t mean that new research should be ignored.

I do recognize that creating a comparable system is a major undertaking, but that is only more reason that innovation in this field should be continuous. If it takes five years to develop the proper framework, then work on it should begin at least five years before the current system is made obsolete. The fact that it is difficult to give a timeline for such obsolescence only makes it more essential that work on a higher-level system should begin immediately after the current system is implemented.

Lawrence D'Oliveiro says:

MD5 Is Bad, Don't Use MD5, M'Kay

MD5 has been known to be week for a few years now. All the smart people started moving off it soon after. What happened is that a few certificate authorities (CAs) have been lax. Some CAs have been shown to be lax in other ways as well, so while this is disappointing, it shouldn’t be a complete shock.

The right solution is to drop these CAs’ root certificates from the popular browsers. They can’t be trusted, so they should be dumped.

Twinrova says:

There's no such thing as "secure" in a digital environment.

It’s a cat & mouse game: New technology comes out which makes it easier to crack old technology cryptography.

The certificate cryptography has run its last leg, but this should have been expected. Now that we have even more powerful software at our disposal, it was just a matter of time before this occurred.

What sucks about the cat & mouse game is that often the “break” is found faster than a new development strategy can be enforced.

Or does all this DRM cracking teach you nothing?

Personal note: As a consumer, it is YOUR responsibility to monitor your accounts. You should always review your credit report once per year (it’s free), watch your bank statement DAILY, and be aware passing your credit card/bank info over the internet is NEVER 100% safe (what’s to stop a thief working for the company to steal the number?).

This is why you don’t send information to sites you don’t know/trust.

JJ says:

Re: There's no such thing as "secure" in a digital environment.

The certificate cryptography has run its last leg

Umm, no it hasn’t. Read closer. It’s a fundamentally strong, well-designed system, and one of the optional components of it, which has been known for years to be weak, was finally cracked completely. The rest of the system (i.e. when used with hash functions other than MD-5) is still as secure as ever. In this case, a minor update to CA policies (stop using MD5) and web browsers (to reject or warn about use of MD5) solves the problem quite simply.

often the “break” is found faster than a new development strategy can be enforced.

Not in this case. I would bet that modern public-key encryption won’t be completely cracked until the development of quantum computers.

Or does all this DRM cracking teach you nothing?

That’s right, all this DRM cracking teaches us nothing at all about public-key encryption. Cracking DRM is much easier, because every user is necessarily given both the key and the lock, and someone just has to figure out how they work together. There’s no such thing as un-crackable DRM. The tech guys realize this, but the media companies don’t, so there’s a huge industry of con artists selling new “stronger” DRM schemes to media companies and then acting surprised when they get cracked.

If you aren’t part of the solution, there’s a lot of money to be made in prolonging the problem!

Old_Paranoid says:

MD5 ongoing usage

Some CA’s have been lax. Given the publicity now, it is my understanding that they will move to more modern hashes shortly. While SHA-1 is more resistant, we expect the first collision to be generated in SHA-1 shortly. Thus, we need to be moving to the stronger hashes of the SHA-2 family in the near future. I expect a long transition time though, as SHA-2 support and integration in cert validation is limited at best in legacy platforms.

The real problem here is not the root certificates. The root organizations will be updated shortly. It is in the secondary certificates, which are rooted in a cert that uses MD5.

As I understand it, this vulnerability relies upon a malicious applicant who provides one data string to the CA for cert generation, having previously generated another string with the same hash. As I understand it, much of the data is provided by the applicant, including the cert issuance time, which may not be verified by the CA when the cert is issued.

Unfortunately, many standards still require MD5, such as digest authentication. This is clearly a problem.

TG says:

This is not a crisis in any sense of the word.

Some Certicate Authorities are offering SSL certificates with no verification at all, so the application of creating two certificates with colliding MD5 hashes, getting the one certified and then using the other, is limited at best. There’s nothing to be gained from this.

In practice, no one cares about the browser warnings they get even when SSL certificates are outdated or wrong, because we’re so used to them by now from lazy companies who can’t be bothered to certify the right domain name.
We all just click through the warnings because we want to use the site.

If you don’t believe me, take it from a guy who really knows what he’s talking about: http://www.schneier.com/blog/archives/2008/12/forging_ssl_cer.html

The only thing this research hopefully does, is to serve as a wake-up call to everyone to stop using MD5 because it was cracked years ago.

Leave a Reply to Anonymous Coward Cancel reply

Your email address will not be published. Required fields are marked *

Have a Techdirt Account? Sign in now. Want one? Register here

Comment Options:

Make this the or (get credits or sign in to see balance) what's this?

What's this?

Techdirt community members with Techdirt Credits can spotlight a comment as either the "First Word" or "Last Word" on a particular comment thread. Credits can be purchased at the Techdirt Insider Shop »

Follow Techdirt

Techdirt Daily Newsletter

Ctrl-Alt-Speech

A weekly news podcast from
Mike Masnick & Ben Whitelaw

Subscribe now to Ctrl-Alt-Speech »
Techdirt Deals
Techdirt Insider Discord
The latest chatter on the Techdirt Insider Discord channel...
Loading...