The Growing Importance of Protecting Certificate Authorities

Sunday, April 08, 2012

Rafal Los

0a8cae998f9c51e3b3c0ccbaddf521aa

As I catch up on news and headlines from recently, this story on SANS NewsBites Vol. 14 Num. 24 caught my attention - "Mozilla Switches to Default SSL Google Searches". 

InformationWeek has a story about this too... and while I'm thrilled that the default Mozilla browser will soon send search queries to Google default-encrypted, I still see a massive gap in the other browsers such as Internet Explorer, Chrome and even Safari.

I also wonder when other search engines (yes, there are others besides Google) such as Bing! will do the same.  There's another issue though, which comes along with more and more traffic on the Internet being SSL encrypted.

As the volume of SSL traffic increases, and the number of sites, applications, and tools running over encrypted channels by default increases it becomes increasingly apparent that the management of those SSL Certificates becomes exponentially more critical.

We've seen a few of the largest root certificate authorities (those that are allowed to legitimize other issued certificates) get compromised (Comodo, DigiNotar come to mind) and as a result fake certificates for organizations like Google and others ended up in the hands of nation-states which wanted nothing else but to spy on their population.  It probably goes without saying that there are likely more attacks like this that we've simply either not picked up, or that were unreported.

What does it mean for today's information security infrastructure?  Well if you're one of those organizations that is running a certificate authority either for internal use, or for your customers and external users you have to definitely focus your attention on protecting the infrastructure which runs your certificate generation and management system.  Seems simple, and obvious, right?  Apparently not since even root CA's are getting hacked, and hacked thoroughly!

The thing that concerns me is that we're not talking about script kiddies here.  The attacks that have penetrated the root CA's out there have been demonstrated to be highly planned, highly evolved attacks.  Defending against these types of attacks goes beyond having the mere basics installed.  Having active defenses, monitoring systems and users closely and perhaps most importantly knowing your own infrastructure are paramount.

The good news is that there aren't a lot of certificate authorities out there, and even less root CAs on the Internet.  Just looking into your browser you can see how many there are - but thanks to processes like delegation and certificate chaining there are more organizations out there that can authoritatively pretend to be someone they're not. 

Take for example your company.  If you're using proxies, odds are that your organization is installed in your browser as a trusted root CA (trusted issuer) and your proxy intercepts even SSL (HTTPS) connections out to the Internet.  The reason your browser doesn't  complain when you connect through your proxy and it pretends to be Google is that your company has an SSL certificate for Google... to explain this proxying concept is beyond the scope of this post - but you can figure out how this is quite dangerous.

A million and one reasons why certificate authorities are so critical today, and why IT Security departments must do a much better job protecting them - whether you're Google, Comodo, or the ACME Widget Corp... if you operate a certificate authority that browsers trust - it is your duty to protect that CA. 

This duty compounds every day as more stories like this one pop up in the news and innovations continue to make everything from mobile browsers to airplane seat-back devices capable of SSL communications.

Cross-posted from Following the White Rabbit

Possibly Related Articles:
6329
Webappsec->General
Information Security
Encryption SSL Digital Certificates Trust HTTPS hackers Comodo DigiNotar Certificate Authority
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.