VMware and SSL Settings: How to Stay Safe

Proper use of Secure Socket Layer security is a mystery even to many virtual server administrators, but it seems to be mysterious even to the developers who build it into their products—whether they know it or not.

The VMware v3.5.x Configuration Guide states that SSL is not enabled in the virtualization software by default. It claims that the initial contact between components is protected but no further communication.

While my previous blog on the SSL MiTM attack refutes even the first statement, I didn’t mention that the data being communicated along with those early packets is mainly credential information, which should be protected. I also didn’t go into whether we need to protect the rest.

Before we can answer that question we need to understand how the traffic is transferred and between what points. There are at least two systems involved, if not three. So a quick summary of communication is needed.

The first connection is between the VMware Infrastructure (VIC), Remote CLI (RCLI), or VI SDK client and the Virtual Center Management Server (VCMS).

The second connection depends on what you plan on doing. You could also need to connect from VCMS to the virtualization host. Alternatively, you may be connecting from VIC, RCLI, or VI SDK direct to the virtualization host.

Now throw in all the other management tools such as Life Cycle Manager, Stage Manager, and Lab Manager and you have even more connection points.

After credential data is transferred to the VCMS or host, anything else that is transferred could be construed as information leakage. Specifically, you have machine names, configurations, network names and configurations, storage names and configurations, advanced options and even security settings data.

The configuration guide does state you need to install new certificates and enable certificate checking. This is one of the better suggestions. From where do you get your certificates?

If you are a large organization, involved with HIPAA, or the government, you may already have a certificate from a known certificate authority like RSA, for example. But if you are an SMB or small organization, these certificates are expensive.

The configuration guide further states that self-signed certificates are vulnerable, which they are. Yet, the guide covers a small aspect of the entire picture (namely ESX). There needs to be a concise guide on how to replace certificates that are used to manage the entire virtual infrastructure.

There also should be some sort of map that explains how the management tools interface with your virtual infrastructure. Knowing this will allow you to know how to further protect your system.

However, it is unclear if after credentials are sent (if even with new certificates) if subsequent data is also sent over SSL. The implication is that it is, but just replacing a certificate would only further protect the items sent over SSL (namely credentials) and not subsequent data.

The best suggestion is to replace the SSL certificates in use. However, you have to understand the management data pathways and protect your management workstations and servers as well.

Virtualization expert Edward L. Haletky is the author of “VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers,” Pearson Education (2008.) He recently left Hewlett-Packard, where he worked in the Virtualization, Linux, and High-Performance Technical Computing teams. Haletky owns AstroArch Consulting, providing virtualization, security, and network consulting and development. Haletky is also a champion and moderator for the VMware discussion forums, providing answers to security and configuration questions.