« February 2011 | Main | April 2011 »

10 posts from March 2011

03/31/2011

Links - Threats to Cloud Computing

Today, I stumbled across a few links to various articles talking about the latest batch of threats to cloud computing, which I thought others might find interesting as well.  The first post is from the privatecloud site, which appears to be sponsored by EMC, Cisco, and VMWare titled: 5 Overlooked Threats to Cloud Computing.  It is a repost from a DataMation article that appeared the same day, which is much more ad-friendly!  ( Please note that storage, networking, and virtualization are not noted as threats. :)

Over at the CCSK Guide, "Top Threats to Cloud Computing" summarizes a recently published pdf whitepaper with the same title from the Cloud Security Alliance.  The blog posts summarizes, the whitepaper goes a little more in-depth.

03/28/2011

CryptoNark v0.4.1 Released

This new version of my pci complance mitigation verification script becomes even more Modern Perlish by incorporating the Mozilla::CA module for SSL certificate verification.  This lets me remove the cacerts.pem file I had included with version 0.4 and gives all of us the ability to upgrade it via cpan as updates become available.

Also new in this version is hostname verification during the certificate validation phase, which will cause cryptonark to gracefully exit in the event the hostname in the request does not match the certificate name.

Finally, I've embedded pod documentation inside the script.  Running " perldoc cnark.pl " now displays a man page for CryptoNark!

Both the main CryptoNark page and the Downloads page have been updated.  Downloads are available in either tar.gz or zip formats.  A change history is on the main page and has been incorporated in the perldoc.

03/24/2011

Notes on the Recent Comodo SSL RA Compromise

By now, a lot of people have heard about the recent ssl certificate registration authority compromise of a Comodo affiliate but if you have not heard, my understanding of the event is that a Comodo certificate reseller was breached.  The breach resulted in the issuance of 9 certificates from 7 different domains which obviously, were signed by Comodo as CA .  The common names for these certificates included some very high profile sites:  mail.google.com, login.skype.com, login.live.com, and login.yahoo.com to name a few.  More information on it can be gathered from a Microsoft Advisory as well as from a Comodo blog entryFirefox and Chrome have also issued advisories—there has been nothing yet from Apple.  These certificate have been revoked and were supposedly revoked within hours of their issuance.

Mike Wood at Sophos has a good write-up on the incident and includes things that users of Internet Explorer and Firefox can do to tighten security within their browsers because the configuration defaults in some versions of these browsers are not good enough.

What makes this so troubling of an event has been summed up well in this post by Johannes Ullrich from the SANS Technology Institute:  

"Probably even worse then the possible man in the middle attacks that may have happened is the simple fact that this fundamentally breaks the trust model of SSL."  

I will go one-step further in stating that this type of incident considerably lowers my trust in the Certificate Authorities.  SSL Certificate issuance was already a pretty shady business to begin with but now we've gotten to the point that we can't necessarily trust the product being sold.  This certainly isn't the first time that fraudulent certificates were issued by a Comodo reseller.  Should we consider any certificate signed by Comodo as potentially fraudulent now and perhaps color the address bar yellow if a Comodo-signed certificate is encountered?  I wonder what Comodo's and this reseller's PCI Cmpliance status will be.

Hopefully, this incident will see the death of domain-validated ssl certificate once-and-for-all.  Another thing I hope is that CAs will give up on this silly Extended Validation certificate nonsense and apply these stringent validation steps to all 'traditional' organization validated certificates, which is what they should have been doing all along.