eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
EV-SSL certificates have been available for about a year. The absolute numbers of them are low, but the growth rate looks good on a line graph and it’s not like everyone is supposed to have them.
They’re a good thing I think, although they’re less about combating phishing than inspiring confidence in genuine sites. VeriSign even has a new Coen Brothersesque marketing campaign for them, No More Abandoned Carts, which -very subtly-promotes EV certificates as a way to keep customers from abandoning carts.
But what about code signing certificates? I’ve long been a qualified fan of code signing certs. If you have the proper perspective on them, they can provide valuable information that you can use to assess whether a program file is trustworthy.
Of course you can’t blindly trust a program just because the file is signed. By whom is it signed? Is the signing certificate issued by a trusted authority?
One problem with this system was demonstrated recently with some malware written up by Sunbelt Software in this blog entry. The interesting part of it is that the malware was digitally signed. The certificate used to sign it was issued by the UserTrust network, which is run by genuine certificate authority Comodo (the specific name is UTN-USERFirst-Object).
Comodo revoked the certificate shortly after it became clear that it had been used to sign malware. It’s uncommon, but this was a certificate sale that had survived an actual identification check. The buyer lost their certificate for having violated terms of service.
Two things that make code signing certs less accessible to hackers are that vendors like Comodo and VeriSign actually do some verification of identity before issuing a cert. They have terms of service which prohibit abusive practices and provide a web form on which 3rd parties can rat you out for violating those terms. And the certificates are expensive: hundreds of dollars a year.
It’s true that the questions a user needs to ask when presented with a code signing cert are difficult ones involving complex concepts. This was one of the problems the CA/Browser Forum attempted to deal with when designing EV-SSL.
There’s talk now that the CA/Browser Forum will now take up code signing certificates, and of this I am much less sanguine.
Prior to EV, if you wanted to check who issued a cert you needed to dig down through several complex dialog boxes. EV certs also set user interface standards for browsers; as part of the green bar you immediately see the name of the company that owns the cert. Click on that name and you immediately see the name of the issuing CA. And a hacker can’t just make up their own CA and issue certs, the browser maker (or Microsoft for IE) has to know about the CA and include it in their trusted roots list. This is a pretty good thing.
So code signing certs could benefit from better user interface, but do we really need an industry organization to do that? It’s not like OS vendors treat code signing certs in remotely similar ways now. What’s really needed is clearer and more prominent treatment of certificates by OS vendors, especially Microsoft. They started making things better in Windows XP SP2, but if they really take code signing certs seriously they need to bring this information out into the user’s face and explain it. Microsoft also needs to be diligent about who they allow into the trusted root certificates list.
Conventional code signing certs may be expensive, the Lexus of the cert world, but EV certs are Bentleys. $1500 for one year from VeriSign. Not a lot of money if you’re protecting and promoting a popular and valuable brand. But if the CA/Browser Forum intends to bring this sort of pricing structure to the code signing world they’re setting up for failure. These $179 certificates don’t sell well enough; raising the price can’t help.
Lots of security experts deride code signing because it’s not perfect. But it’s a necessary element of many systems for securing software. If you would ever want to implement a whitelisting system for software, you’d probably need to use code signing for it, for example. Code signing is widely used by mobile networks to control what code gets on to phones. This market needs to be made more accessible.
Editor’s Note: This story has been corrected to make clear that the malware in the attack was signed with a standard Comodo code signing certificate which was purchased at standard price, and was revoked when Comodo determined that it had been abused
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
For insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer’s blog Cheap Hack