I traditionally don’t write much about compliance. I’ve been very focused on security. But some might ask “Aren’t they the same thing?” My answer is unequivocally “No” but remember, this is my opinion and in the world of security, we are all entitled to our opinion, right?
Security vs. Compliance
Security is a practice. It’s not a destination. You’ll never reach a point where you can say “We’re secure”. Why? Because the threats are constantly evolving. As you add new technologies you add new threat vectors. As code is poked and prodded, bugs are found. And as we all know as new software is developed in some organizations, security may take a back seat to expediency in releasing the product until such time as you find yourself facing a mountain of vulnerabilities. It’s ok, that’s just how things go and in many cases, compensating controls can minimize the risk. It’s part of the journey.
Compliance on the other hand is a measurement. “On this date at this time, we met all the requirements to say we are complaint with “X”. ” Compliance can be a driver of security. In some cases, compliance regulations can actually affect security negatively if it’s they don’t keep up with technology advances. However, because human nature compels us to do the least amount possible to “check the box” and be done with things ASAP, its unfortunate that some see compliance as the end state. If you’re doing the minimum to “check the box” and get the auditor out of your sandbox and not constantly evolving your security practice and processes then sure, you may pass the audit but you may not be, in fact, secure.
PCI: The driver for change in TLS
This leads me to PCI. It’s a great standard set by a bunch of smart people in the Payment Card Industry. It’s constantly evolving to recognize new threats. One of those threats came about when PCI 3.1 introduced a higher standard for strong cryptography using TLS (Transport Layer Security). TLS is the replacement for SSL. However, TLS 1.0 was discovered to have some known weaknesses. If a service offered up TLS 1.0, 1.1 and 1.2 and you were running an older browser that didn’t support 1.1 or 1.2 then your connection would be over the weaker TLS 1.0. That’s not good. You’d want to disable the ability for any 1.0 connections to happen.
Note:TLS 1.1 is still considered “safe” for PCI but many customers are already asking how they can go to 1.2 directly.
Now, there’s two ways to mitigate using TLS 1.0.
You could update all your browsers so that they would always negotiate their connections to the higher standards
You could disable offering TLS 1.0 and/or TLS 1.1 by services such as vCenter.
There are implementation challenges with both of these options. You can scan your environment to ensure that only compliant browsers are being used. Ideal? No. Effective? Depends. For the second option, changes are necessary in the product. These changes are non-trivial and require a lot of thought. Here are some of the considerations.
Cryptography solutions such as OpenSSL will need to be updated. How will this effect other code in the application. Were assumptions made?
Not just browsers connect to vCenter. Applications like Horizon View and other 3rd party/custom applications make secured connections to vCenter over TLS. Has their code been updated to use TLS 1.2?
If we ship with TLS 1.0 and 1.1 disabled, are we going to cause a Denial of Service? If so, how do we help the customer back out?
So, as you can see, it really is an exercise that requires a lot of thought and planning. The last thing we want to do is have a customer install a security patch and then everything they depend breaks by not being able to connect to vCenter! I suppose some might say “things are now secure” but that’s not exactly a good way to run a business if nothing works!
Where is vSphere today?
I’m happy to announce that we have met the TLS challenge head on. Through a HUGE amount of hard work from VMware R&D we can now ship vSphere 6 Update 3 and vSphere 6.5 with a tool to disable TLS 1.0 and 1.1 when YOU are ready!
Let’s be clear, TLS 1.0 and 1.1 (and 1.2) are enabled by default on vCenter 6.0 U3 and 6.5 today. Upgrading to either version will not break any of your applications that are not yet updated to TLS 1.2.
For both of these versions, you will see a TLS Reconfigurator tool for Windows and the VCSA in the download page. Running this tool will disable TLS 1.0 and/or TLS 1.1 on vCenter. Older browsers that don’t support TLS 1.1 or 1.2 (why are you running them?) will not connect to the vSphere Web Client. Please, plan accordingly.
There is a chart available in KB 2145796 that will show you the status of all of the VMware products and their versions that have TLS 1.0 and/or 1.1 disabled.
Within vCenter you can see which versions of TLS are enabled for each service using the TLS Reconfigurator tool.
If you find that a 3rd party tool is not working you can revert back to using the older TLS versions. These steps and more are all called out in KB 2147469. Every time the tool is run a backup of the existing configuration is made.
Where to go for more info
vSphere 6.5
Managing TLS protocol configuration for vSphere 6.5 (2147469)
Finally, I’d also like to point out the herculean work done by Dan Raymond who kept everyone corralled and facing in the right direction and Blair Fritz who rode herd on all of the KB articles and drove everyone to keep simplicity at the front of mind.
