VMware’s Project Octopus and others like ownCloud and Oxygen Cloud have stirred some interesting ideas about Application Security. Those applications that make use of SSL, nearly every web application, can make use of secure cloud storage for certificate verification means. What makes SSL MiTM attacks possible, is mostly related to poor certificate management. If there was a way to alleviate the need for the user to be involved in this security decision, then SSL MiTM attacks would be significantly reduced.One way to do this is to pre-share all certificates using an out of band mechanism, such as USB keys, CAC cards, etc. These methods are ideal, but unless you have the means to make such transfer of devices in person, you may never know who has the certificate data (even if it is encrypted). So perhaps, we can develop another out-of-band mechanism to act as such a data store of certificate digital signatures and fingerprints.
Why do this? Because everyone gets the browser dialog box that says the certificate being used by a site is unknown, and what have we been trained to do? Hit the ignore button. How many people have been trained to properly review the certificates? How many even know to find the data to which to compare the certificates? In both cases, not many. This is the browser or application leaving up to the user a difficult security question that can be bettered answered by a programmatic means. In other words the application client needs to verify the server certificate and when it does not verify properly disallow the connection, leaving nothing up to the end user.
For banks that programmatic means is provided by Trusteer, who work with very specific customers to verify that the server certificates are the correct ones, and to deny access to a site if the certificate is not known. Trusteer uses Amazon S3 as an intermediary transfer point for certificate data, which the local computer can then use to verify certificates. What if all applications could do this, use a cloud storage solution as a secure certificate store?
The concept is pretty straight forward, build applications to use the secure cloud storage device as a store of data to verify the server certificate before allowing access to the server? Into this breach would end up services such as ownCloud, VMware’s Project Octopus, Oxygen Cloud, and even dropbox using encrypted containers such as ones produced by TrueCrypt.
This, however, does requires changes to applications:
- Be modified to increase security by verifying server certificates
- Be modified to use the cloud data storage as a certificate store for security verifications and decrypt the storage using application keys
- Cache security information for those times when the cloud storage is not available
- Use Role-Based Access Controls (such as provided by Symantec CSP) to govern who and what can access the secure cloud storage
These simple steps will make use of private cloud storage tools (Project Octopus, ownCloud) as well as public cloud offerings (Amazon S3, Oxygen Cloud, Dropbox) as a repository of security data for certificate verification. The certificate’s themselves do not need to be stored, just digitally signed versions of fingerprints and digital signatures of certificates are needed, unless a more detailed examination and verification process is required. Reducing the amount of data stored, reduces the possibility of abuse of that data.
What does this provide? A simple way to verify SSL based certificates to alleviate SSL based MiTM attacks, but to begin, the way we write these applications must also change. Yet, the means to have the necessary data available is waiting for us in secure cloud storage. If applied towards virtualization management tools, most of the known attacks against these all important tools (such as VMware vCenter) would be alleviated.
Share this Article:
Latest posts by Edward Haletky (see all)
- Moving Up the Stack Does not Really Simplify Anything! - September 13, 2016
- VMware Shows a Way Forward - September 7, 2016
- Containers: Distributed Disruption - August 30, 2016