Marlinspike: Certificates have 'real problems'

Summary:Security technologist Moxie Marlinspike tells ZDNet UK why he thinks there are major problems with trust in digital certificates after a series of certificate authority hacks in 2011

Last year, hackers perpetrated a series of digital certificate compromises, striking at a deep level with potentially far-reaching effects both for internet users and the hacked companies.

In March, news broke of a hack of Comodo, when an intruder obtained nine fraudulent digital certificates. Then in September it emerged that hundreds of thousands of Iranians may have had their Google communications intercepted after a compromise of Dutch certificate authority DigiNotar. DigiNotar declared itself bankrupt after the hack resulted in the Dutch government revoking trust in its certificates.

Certificate authority GlobalSign stopped issuing certificates while it investigated a hack on its systems in September. It later found that its SSL certificate had been exposed during the attack on an external server.

A major problem with certificate compromise is the undermining of trust in numerous security mechanisms. An attacker can set up a website that looks bona fide, and trick people into thinking they are visiting one website when it is in fact another. An attacker can also white-list malware on an operating system to gain full control of a device.

Security technologist Moxie Marlinspike has come up with a technology called Convergence, designed to overcome the need for organisations to rely on digital certificates. He spoke to ZDNet UK about the technology, trust, and anonymity.

Q: Last year a number of certificate authorities were compromised. Do you think the certificate authority model is broken?
A: There are very real problems here. My thesis is that what we have now lacks what I call 'trust agility'. We've made a decision somewhere along the line to trust these organisations, and now it's very difficult for us to untrust them.

So, they don't have a tremendous amount of incentive to continue engendering our goodwill, or behaving appropriately, or employing the best security practices.

Why is it difficult to revoke trust in them?
Comodo is a good example. Right now, Comodo should apply somewhere between a quarter and a fifth of the certificates on the internet. So if I, or a browser vendor, decides that they no longer trust Comodo, and remove them from their trust database, that means that that quarter to a fifth of the internet will basically break — you wouldn't be able to look at those websites any more, until they've all gotten different certificates from different certificate authorities.

That's a really tough business decision for a browser vendor to make — that they're going to break a quarter to a fifth of the internet for their users, or, that they are somehow going to try and co-ordinate a quarter to a fifth of the internet to migrate to some other certificate authority.

Your Convergence project seems to be making the trust model open source, or making a collective decision, through various different trusted authorities.
The major objective is to provide trust agility: the idea that we still rely on third parties to certify a communication, but that you can untrust them at any time. You can make a decision to trust some organisation or set of organisations, but at any time you can revise that decision if you decide that they no longer warrant your trust.

It does additionally provide properties that allow you to rely on organisations to collectively certify communications. So you can decide you don't want to trust any individual organisation, but five different organisations. If they all agree, then you consider that an indication to be certified.

The system of notaries — doesn't that rely on some kind of user technical savvy, and is that beyond the purview of most people, and most employees of organisations?
The way I see it is that ideally Convergence would be based in web browsers — web browsers using Convergence as the mechanism for certifying secure communications. The web browser would come with a default set of notaries, just like today a web browser comes with a default set of certificate organisations. Most users would never change their notaries, and they would depend on their browser to make those appropriate decisions for them. I think that's entirely reasonable. Users could decide to modify the notaries if they liked.

How would you define a notary?
A notary is very similar to a certificate authority. The only difference is that the trust relationship is inverted. Right now servers initiate a trust relationship with a certificate authority, which means that one server or website will make a decision about the organisation that's going to certify all the traffic for all users around the world, whereas notaries are selected by the client — the client initiates the trust relationship, first connecting to the notary and asking it to certify communications.

The major problem with the model right now is that if the certificate authority is compromised, then that affects all users for all websites.

With the certificate authority model, are there any particular security problems with servers initiating the trust relationship?
The major problem with the model right now is that if the certificate authority is compromised, then that affects all users for all websites. They can continue to operate purely because even after a compromise it's difficult to untrust them.

My problem with VeriSign as a manager of TLDs [top-level domains] is that I think it would be unwise to place all our trust there. Under the DNSSEC model there would be reduced trust agility. Even as unrealistic as it might be, today I can remove VeriSign from the trust database in my browser or my operating system, but I can never change the fact that they are the organisation that manages dot.com and .net domains.

Are attacks on certificate authorities inevitably state sponsored?
My intuition is that of the attacks that we've seen with organisations like Comodo and DigiNotar, [they] were not state-sponsored attacks. You have a not very bright hacker, based on...

Topics: Security

About

Tom is a technology reporter for ZDNet.com, writing about all manner of security and open-source issues.Tom had various jobs after leaving university, including working for a company that hired out computers as props for films and television, and a role turning the entire back catalogue of a publisher into e-books.Tom eventually found tha... Full Bio

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Related Stories

The best of ZDNet, delivered

You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
Subscription failed.