Why Certificate Security Matters

CA Hackers Could Create Spoofed Sites to Fool Users
Why Certificate Security Matters

Hacks waged against companies that issue security certificates for websites are calling into question long-standing domain name verification practices.

See Also: Webinar | 3 Things To Consider When Building A Secure Identity-Based Perimeter

The most headline-grabbing attacks, launched by the so-called Comodohacker against certificate authorities Comodo and DigiNotar, aim to gather certificate information for frequently used social sites such as Google. With certificate information, anyone with access controls at an Internet service provider could easily create a ghost site, one that under common Internet browsing behavior and standards would be difficult for the average Web user to spot. With a ghost site, hackers could attempt to defraud unsuspecting users.

Difficulty in citing suspicious ghost or spoofed sites has been exasperated by mobile browsing. "We could be browsing fake sites, a fake Google site, and not know that we're doing anything badly," says Bob Walder, chief research officer at NSS Labs, an IT security research and testing firm. "The train of trust will appear to be unbroken on an iPhone and Android phone."

Part of the problem is user behavior. Most online users trust that sites matching the URLs they enter are safe. But another part of the problem lies in the way certificates are verified - ultimately a system that has been built on trust and honors, say security experts such as Michael Smith of Akamai Technologies.

"We have this problem on the Internet, which is, 'How do I talk to someone I've never met before and know that they are who they say they are?'" Smith says. "No. 1, the CA [certificate authority] has to be recognized by the browser. No. 2, the domain name system has to point the Web browser to your service; and No. 3, you have to have the private key on your server and the certificate."

And there's little that businesses, organizations and governments can do to enhance the certification behind their sites.

Certificate Security and Browser Verification

Certificate security is based on browser verification, which more often than not is based on trust - the browser white-lists certain domains and black-lists others. That method has, up until now, worked well. But it likely won't pass the acid test going forward.

"It all works on this basic premise," Smith says. "Inside my Web browser, there are addresses that my browser trusts. Browsers vary, and this is the interesting thing. ... It's not necessarily about stealing the certificate. The certificate has to be public. It's the private key behind the certificate that poses the most potential risk if hacked."

Smith says companies can implement additional authentication layers, which include certificate testing and two-factor authentication before a site URL is opened, to add an extra layer of security.

"It's basically to say, 'Prove to me that you have the valid key,'" Smith says of the certificate testing. "On top of that, if you use something like two-factor authentication, then I also send an SMS to somebody's mobile device," to verify that the site is legitimate.

Google, for example, has a two-factor option called Authenticator, which changes every 60 seconds to prevent copying or compromise. "On the log-in page, you have the username, password, and then give the code that your Google Authenticator provides," Smith says.

It's more about building checkpoints into the browsers. But many of the security precautions could be moot, based on the hacker's motive. Going back to the March hack at Comodo and the August attack on Netherlands-based DigiNotar, security experts are trying to get to the bottom of what the hacker or hackers actually wanted.

Though the motives behind the attacks are questionable, many industry pundits believe the attacks were backed by the Iranian government.

Smith says there is no definitive connection between Iran and the Comodohacker, but based on the kinds of certificates that were targeted, it appears some nation-state or governmental body was behind the hacks.

"I've heard lots of allegations," Smith says. "There's quite a bit of speculation out there. You'd have to look at the sites that were actually cloned and see what information you would get out of them. In this case, they were just popular sites, social networking sites. ... It almost seems like it's more eavesdropping on users, than it is trying to steal people's money or any kind of weird crime thing going on. I think that's what led people to look to Iran."

The Browsing Perspective

Jerry Bryant, group manager of response communications for Microsoft Trustworthy Computing, says Microsoft's Internet Explorer assures users that sites are legitimate by displaying lock icons in the browser security status bar. "That will let the user visiting the website know that the site has a digital certificate," he says. "The certificate that is used to encrypt the connection also contains information about the identity of the website owner or organization. You can click the lock to view the identity of the website. Normally, you won't have to think about certificates at all. You might, however, see a message telling you that a certificate is expired or invalid. In those cases, you should follow the instructions in the message."

Microsoft says it uses a variety of technologies to validate the trust of certificates, one being a Certification Revocation List - a digitally signed list issued by a CA that contains a list of certificates that have been revoked. "For each individual revoked certificate, the listing includes the serial number of the certificate, the date that the certificate was revoked and the revocation reason," Bryant says. "Windows will check this CRL and determine the trust of the certificate."

But as Smith points out, the verification used varies from browser to browser. IE's method is not likely duplicated by Firefox.

Vik Phatak, chief technology officer at NSS Labs, who shared thoughts about certificate security during a recent webinar, says any attack would require rerouting traffic to a so-called "bad actor."

"So the biggest way to protect yourself is to make sure your DNS servers are secure, and, again, make sure that you revoke those certificates," he says.

NSS Labs' Walder, also speaking at that webinar, says despite all the security measures organizations implement to enhance security and authentication, those measures can only go so far. To that end, the onus is on the mobile-device vendors to make trusted roots configurable by the end-user. "It's one more example of how the mobile revolution can leave enterprises exposed," Walder says.

Executive Editor Eric Chabrow and Associate Editor Jeffrey Roman contributed to this report.


About the Author

Tracy Kitten

Tracy Kitten

Former Director of Global Events Content and Executive Editor, BankInfoSecurity & CUInfoSecurity

Kitten was director of global events content and an executive editor at ISMG. A veteran journalist with more than 20 years of experience, she covered the financial sector for over 10 years. Before joining Information Security Media Group in 2010, she covered the financial self-service industry as the senior editor of ATMmarketplace, part of Networld Media. Kitten has been a regular speaker at domestic and international conferences, and was the keynote at ATMIA's U.S. and Canadian conferences in 2009. She has been quoted by CNN.com, ABC News, Bankrate.com and MSN Money.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing inforisktoday.com, you agree to our use of cookies.