Disable TLS v1.0 and v1.1 in vSphere 6.0

This is a very rough post with the base information - I will make this part of a series soon. 

This quick post only focuses on the use of the TLS tool in vSphere 6.0 in a very simple environment (VCSA with embedded PSC, hosts in the 3 situations used in the tool) for demonstration purposes. 

Also, note that only port 443 is tested, but both vSphere and ESXi have many other ports, some even outside of the TLS tool configuration.

This post focuses on only leaving TLS 1.2 enabled. Other posts which helped me and constitute good reading are:

https://techbrainblog.com/2015/03/30/how-to-scp-files-to-vmware-vcenter-appliance-6-0-vcsa/ by GaneshSekarbabu

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2054085

http://www.justmy02centsworth.com/2016/11/pci-dss-tls-10-disablement-and-vmware.html by DanRaymond65

We will basically put in practice KB 2148819:

https://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2148819

Before we start, make super sure you are running at least 6.0 Update 3 and your vCenter and hosts are on the same release! Also download the rpm version of the TLS tool from the same location where the VCSA is downloaded from.

If you are going to do the whole environment, the basic order is:

1) vCenters
2) hosts
3) PSCs

Steps needed to be able to run the tool:

#Open SSH (or use the VCSA console). You may need to follow this if it's not enabled already

#It's always a good idea to verify the SSH keys match

#Now execute these commands. Enable Bash shell:
shell.set --enable True

#Launch the "Bash" shell which is really a "pi shell":
shell

#Change shell to Bash so SCP works (doesn't otherwise, not explained in the KB)
chsh -s "/bin/bash" root

*Go copy the TLS RPM file to the VCSA now*

#I copied the file to /tmp (or wherever, but notice you have to change the directory to what you used)
cd /tmp

#U is upgrade (assumes install if no older version found), v is verbose, h is hash (progress display)
rpm -Uvh VMware-vSphereTlsReconfigurator-6.0.0-5051284.x86_64.rpm

#Change directory to where TLS Reconfigurator was installed to
cd /usr/lib/vmware-vSphereTlsReconfigurator/


vCenter and PSC steps

#Switch to vCenter tool directory 
cd VcTlsReconfigurator

#Take a backup as per the KB
./reconfigureVc backup

*Go copy the backup directory to a safe place. Why? WHY NOT?*

Note a scan of port 443 before running the tool using sslscan (from a windows executable) shows TLS 1.0 and 1.1 are active:

#Do some damage! I mean, set TLS v1.2 as the only accepted protocol
./reconfigureVc update -p TLSv1.2

#Type a "y" to proceed. It doesn't really re-start the whole appliance, just the services

#Note it actually takes another backup. Gotta protect GSS :)

#Finally you will get a status report which confirms that only TLS v1.2 is configured

#The vSphere Client service takes a little longer to start than the rest. You can monitor it via the shell with
service vsphere-client status

#Note a scan of port 443 after running the tool shows only TLS 1.2 is now enabled:

ESXi steps

#Hosts MUST be rebooted after these commands for all changes to take effect!!

#Switch to ESX tool directory 
cd /usr/lib/vmware-vSphereTlsReconfigurator/EsxTlsReconfigurator

You have 3 options for host changes - by cluster, by host joined to this vCenter, or standalone hosts.

#If you are doing hosts joined to a vCenter inside a Cluster (this does the whole cluster)

#./reconfigureEsx vCenterCluster -c <Cluster_Name> -u <Administrative_User> -p TLSv1.2
./reconfigureEsx vCenterCluster -c MyCluster -u administrator@vsphere.local -p TLSv1.2

#It asks for the user's passwords and executes

#Don't forget to reboot the host!
#Scan before change

#Scan after change and reboot

#If you are doing one host joined to a vCenter

#./reconfigureEsx vCenterHost -h <ESXi_Host_Name> -u <Administrative_User> -p TLSv1.2
./reconfigureEsx vCenterHost -h 192.168.1.102 -u administrator@vsphere.local -p TLSv1.2

#It asks for the user's passwords and executes

#Don't forget to reboot the host!

#Scan before change

#Scan after change and reboot

#If you are doing a host that is not joined to a vCenter

#./reconfigureEsx ESXiHost -h <ESXi_Host_Name> -u <User> -p TLSv1.2
./reconfigureEsx ESXiHost -h 192.168.1.103 -u root -p TLSv1.2

#Note this uses a local ESXi account since this host is not in this vCenter

#Don't forget to reboot the host!

#Scan before change

#Scan after change and reboot

Hope this helps. I'll go into a bit more detail as soon as I have some time! Ping me on twitter if you have any comments please.

Checking SSL/TLS versions for audit purposes

SSL and TLS have long been thought as secure, but several problems have exposed SSL to be insecure. The PCI standard will begin flagging all versions of SSL and TLS 1.0 as insecure in June 2016 (link here). It makes sense as TLS 1.0 was released in 1999.

Many have found the hard way that securing servers will break some things. I learned about Windows server OS support for each cipher by looking at the table in this MSDN article. You can see that when securing servers, the client portion is very important - it's what's holding back many websites from removing old version support. If your legacy application still has legacy clients and you can't modernize both, you will not be able to pass industry certifications, and you will have to fix both.

You can easily check TLS version in most browsers by clicking on the lock icon and fishing a bit - I use Chrome and Mozilla and found the TLS version very easily. 

However my good friend @edmsanchez13 pointed out that McAfee has a free tool called SSLSmart that checks SSL and TLS 1.0 ciphers. This tool is very useful, since these are the problematic versions, and because this is free and can be run by you against internal servers, while testing several ciphers in batch mode. I recommend it for when you are in need of verifying how your internal servers are acting.

It is curious to see how certain websites handle the issue. For example, Google.com uses a HTTP 301 message - moved permanently for some of the older ciphers. The included PDF with SSL Smart tool also explains why sometimes scanning solutions give false positives. For example, https://www.ssllabs.com/ssltest/index.html which is a public and free SSL analyzer, ranks Google with a B in several options, but the problems it finds correspond to the responses that give a HTTP 301 message. It's also interesting to see the Recent Best and Recent Worst list to see good and bad examples for your testing and learning.

I leave here other two good links i found while testing and making this post

• A Mozilla security engineer named Julien Vehent made an analysis of the web's top million websites - his findings here
• https://www.howsmyssl.com/ tests the client (browser in my case)